Changelog

The CLI says when a newer version exists after it rejects an option. An installed withruntime stays at its version until you update it, and npx withruntime runs an installed copy before it downloads one, so an older CLI could reject an option the docs list, such as secrets scope --only-label, with no sign that it was out of date. Now, when the CLI rejects an option or a command, it checks npm for the latest version, for at most 1.5 seconds, and prints the installed and latest versions with npm install -g withruntime@latest. It skips the check in CI and when RUNTIME_NO_UPDATE_CHECK=1 is set (the CLI).

Raising a job's timeout no longer requires changing its compute. Previously, PATCH /v1/jobs/{id} with only a larger timeoutSeconds returned 400 with "Invalid integer" when the new timeout exceeded the job's compute.durationSeconds. Now the update extends compute.durationSeconds to the timeout plus 60 seconds of start time, up to 3,600, as a create does. A timeout that already fits leaves it as it is. Refusals of timeoutSeconds and compute.durationSeconds now name the field and the allowed range.

HTTPS through egress secrets and preview links keeps working after a sandbox moves to another server. Previously each server signed with its own certificate authority, so a process started before a wake, a move or a fork onto another server (such as Node with NODE_EXTRA_CA_CERTS) failed every request to an egress secret's host with SELF_SIGNED_CERT_IN_CHAIN until it restarted. Now each organization has one certificate authority, the same on every server, and running processes keep working. Each sandbox switches to its organization's certificate authority at its next start or wake; a process started before that switch must be restarted once. See Security.

Sandboxes created from older images hold as many outbound connections as their limits allow. Previously a sandbox created from an image or snapshot made before 15 October 2026 kept that image's web proxy relay, which held 64 connections and closed the 65th without a response, even when GET /v1/sandboxes/{id}/network reported a higher limits.connections. Now every sandbox boots with the current relay, so it holds its full limit and a connection past it returns 503 Service Unavailable with the limit in X-Runtime-Egress. A sandbox that resumes saved memory (a wake, or a copy of a memory snapshot) takes the current relay immediately before its next pause, so it holds its full limit from the wake after that. See The network.

Agents that start from a repository start their sessions. An agent whose definition sets from: {"repo": "owner/name"} starts each session from that repository's CI/CD warm snapshot. Previously every session of such an agent ended immediately with sandbox_refused (403 forbidden, "a create naming another snapshot"), because the session's key was allowed to create its sandbox only from a snapshot the definition names by id. A session's key may now create its sandbox from any ready warm snapshot of the definition's repository, and from no other snapshot.

A secret can now be given to the machine as its real value. Some secrets are not HTTPS headers: a database password, an SSH key, a signing key or a service account's JSON file. Store one with --exposed (or exposed: true in the API, the MCP tool and the SDKs) and the machines it reaches get the value itself in its variable. It may be any text up to 64 KiB, several lines included. The value is still sealed, and opened only on the server that runs the machine. Code in the machine can read it, so the placeholder kind stays the default and the one to use for HTTPS APIs. For the same reason, it goes only to the sandboxes and Apps you name by id (--only-sandbox, --only-app), never to every sandbox or by label, and only a key that may run commands in each of them can store it. Which machines get it changes only when you store it again with its value. Every secret now has a version too, one more for each change to it: its value, who gets it, its hosts or its variable. Pass it as expectedVersion (--expected-version) and a write happens only if no one has changed the secret since; otherwise the answer is 409 version_conflict. GET /v1/egress-secrets/{name} and runtime secrets get show one secret's kind and version, never its value. The website's Secrets page offers both kinds and shows each secret's kind and version. See a secret the machine needs itself.

A failed agent session shows why in the console. When a session fails because its sandbox could not be created (sandbox_refused), the session's page in the console now shows the error the API returned, which previously appeared only in the session's events.

App deploys report live only when the address serves them. A deploy reaches live only after every router serves the new version's route, and an App's state is waiting until its first version is served, so waitFor=live, runtime apps deploy and the SDKs return when the address answers from the new version.

CI/CD: built-in and light-sandbox steps record their result immediately. An undoes or hot-spots step, a gate, or a machine: light step now shows its result in the console as soon as it finishes, instead of when the check's other jobs end. Previously such a step stayed "running" until then, and a check whose other jobs waited more than 40 minutes for capacity failed with "undoes sent nothing for 40 minutes" although the step had passed.

GET http://runtime.internal/v1/identity/token returns 401 for a request token that is not the sandbox's current one. It previously returned 403. Read the current token from http://runtime.internal/v1/environment and retry. The JavaScript and Python SDKs already do this for both statuses.

Browsers start with Chromium already running. A headless browser at the default window size (1280 by 800) is now created from a snapshot of Chromium that is already running, instead of starting Chromium in the new sandbox, which took 1 to 3 seconds. Each browser gets its own CDP secret, its own random state, and an empty profile. A server builds the snapshot the first time a browser of that size is created on it, so that first browser starts as before. Other settings start Chromium as before.

An outbound connection that cannot reach Runtime's web proxy returns 503 Service Unavailable with the reason. Previously the sandbox's relay closed such a connection without a response, which clients reported as Connection reset by peer. Now the response carries X-Runtime-Egress: proxy unreachable (<reason>) and Retry-After: 1. A sandbox holds about 1,000 outbound connections at the same time, fewer than limits.connections for a sandbox with more than one vCPU, until a later release raises it; past that, new connections return this response.

A sandbox with no time limit can be funded up to 12 hours ahead. Set leaseSeconds (from its first lease, 1,800 seconds, to 43,200) on create or :update (--lease in the CLI, lease_seconds= in Python, .leaseSeconds() in Java, LeaseSeconds in Go), and each renewal funds it that far ahead instead of 1,800 seconds. It is renewed when half is left, so it keeps running for at least half of leaseSeconds if Runtime's control plane cannot renew it. Each renewal holds that much time's credit at the sandbox's rates; what it does not use is released. A sandbox on the free usage renews by 1,800 seconds until the account has credit. Only an owner's, an admin's or an account-wide key may set it, on a sandbox one of those made. If that key or member loses the right, a sandbox funded past its first lease is paused or stopped at once, as its lease's end would. A sandbox's details include its leaseSeconds.

CI/CD: a cancelled check names the key that cancelled it, and your production branch's check gets machines sooner. A check cancelled with POST /v1/ci/checks/{id}:cancel, runtime ci cancel or the MCP tool now shows the reason asked through Runtime's API with the key "<label>" in the console, in the API's reason field and on GitHub, where <label> is the calling key's label. The audit log entry also includes the key's id. When your account's machine limit is reached, your production branch's check now takes machines from your pull requests' checks as their running tasks end. Previously it waited for those checks to finish when the limit, rather than the servers, held it back.

Slack triggers start agent sessions from a channel. Add Runtime's Slack app to a workspace with runtime agents slack install (or POST /v1/agents/slack/installs; the link works only for a signed-in member of the account), invite it to a channel, and add a slack trigger with the workspace's team and the channel's id. Each new message in the channel starts a session; a reply in its thread joins that session. The session's replies and result are posted in the thread, its status is one message edited in place, and each ask is posted with a button for each option. GET /v1/agents/slack/teams lists the added workspaces and DELETE /v1/agents/slack/teams/{team} removes one. Available in the JavaScript, Python, Go, Java and Ruby SDKs (agents.slack).

SSH to Runtime's own servers counts toward its own limit in the probing check. SSH connections from a sandbox to the public addresses of Runtime's servers are still refused. They now count toward a separate limit of 10 different servers in ten minutes, instead of the limit of 5 internal addresses. Previously, a test suite that tried SSH on five of them within ten minutes could have its sandbox held. Connections to Runtime's servers on other ports still count toward the internal-address limit.

A paid account's sandbox is reviewed by a person before it is halted. When the abuse checks flag a sandbox of an account that has paid, it is held as described above and keeps running, with its processes and files untouched. A person then lifts the hold, which turns the network back on, or confirms it, which pauses the sandbox. Previously, the sandbox was paused immediately.

A sandbox held by the abuse checks keeps its files readable. You can read and download a held sandbox's files with GET /v1/sandboxes/{id}/files/content or GET /v1/sandboxes/{id}/files/archive. A read wakes the sandbox if it is paused, and it can also be woken or started. Previously, every wake and start of a held sandbox returned sandbox_halted (403), so its files could not be read. While the hold is in place, the sandbox's network is off for outbound and inbound traffic (previews, custom domains, TCP ports and private networks), and commands, terminals, file writes, snapshots and forks return sandbox_halted (403). See Network access.

A lease that ends without you never deletes a sandbox's disk. Only a request from you deletes data. Previously a sandbox created with onTimeout: "delete" had its disk deleted when its lease ended before its time limit (a renewal that did not arrive, or a pause that failed at the lease's end), and a sandbox created with pausable: false, one on a server that stopped responding, or one stopped while moving between servers had its disk deleted when its lease ended or it crashed. Each is now kept: a pausable sandbox as a stopped sandbox you can restart, billed as paused storage; the others at no charge, until you delete them. onTimeout: "delete" still deletes the disk when the time limit you set ends.

CI/CD: built-in history checks finish immediately on production pushes. On a push to the production branch, an undoes or hot-spots step now passes as soon as the plan is made, because the pull request was already checked. It no longer waits for a sandbox. On a pull request, these steps still run on the check's light sandbox. While that sandbox, or the one that runs gates, waits for capacity, the console shows "Waiting for room" on each of its jobs, with the elapsed minutes updated every 5 minutes. Previously these jobs showed no update while they waited, and a check whose jobs waited more than 40 minutes failed with "sent nothing for 40 minutes".

Commands in sandboxes and App copies can open 65,536 files. The open-file limit is 65,536, previously 4,096, and a process can raise it to 1,048,576 without root (ulimit -n 1048576), so one server holds tens of thousands of connections. See Limits of one sandbox or one feature.

Move scheduled jobs from Trigger.dev, Inngest, Modal, Google Cloud Run and AWS Batch. Change one import, or run one command, and the jobs run on Runtime unchanged, with their schedules, sizes, timeouts and retries. withruntime/trigger runs Trigger.dev schedules.task and task definitions, and withruntime/inngest runs Inngest functions with cron or event triggers; runtime jobs deploy builds the project and creates one job per task. python -m withruntime.modal deploy app.py creates a job for each Modal Function with a schedule (modal.Cron or modal.Period). runtime jobs import reads a Cloud Run job's YAML with its Cloud Scheduler job, or an AWS Batch job definition (API JSON, describe-job-definitions output or a CloudFormation template) with its EventBridge schedule or rule, and creates the jobs. Settings with no equivalent, such as a GPU, parallel tasks or a mounted bucket, are listed with the reason. The plan is also available as POST /v1/job-imports, jobs.importPlan in every SDK and the runtime_jobs_import MCP tool. Requires SDK 0.36.0 (Python 0.34.0). See Move jobs from another platform.

OpenTelemetry exports can send traces. Add "traces" to an export's signals and every API call your account makes, including creates, commands, file calls, pauses, wakes and snapshots, is sent to <endpoint>/v1/traces as an OTLP span within about a second, with the OpenTelemetry HTTP attributes and the request ID. A call that carries a W3C traceparent header becomes a child of the caller's span; the TypeScript and Python SDKs send that header automatically when OpenTelemetry is set up in your process. Exports now report exportedSpans, and the span pushes' own health in tracesLastSuccessAt, tracesLastError and tracesFailures, apart from the logs' and metrics' lastError and failures. The default signals are unchanged (traces).

Sandbox metrics include disk and network. GET /v1/sandboxes/{id}/metrics and sbx.metrics() now return diskUsedBytes (bytes used on the root file system), diskReadBytesPerSecond, diskWriteBytesPerSecond, diskReadOpsPerSecond, diskWriteOpsPerSecond, networkReceivedBytesPerSecond and networkSentBytesPerSecond for each point and for latest. Disk figures are counted by the sandbox's own kernel; network figures by the host, for every connection the sandbox opens and every request it serves. A value that was not measured is null, never zero. The sandbox's Activity tab charts disk used, disk reads and writes, and network in and out; runtime sandboxes metrics prints them; the Python, Go and TypeScript SDKs return them; and getMetrics() in withruntime/e2b now returns diskUsed. OpenTelemetry exports send them as runtime.sandbox.disk.usage, runtime.sandbox.disk.limit, runtime.sandbox.disk.io, runtime.sandbox.disk.operations and runtime.sandbox.network.io (metrics).

Waking a sandbox paused moments earlier returns sooner. POST /v1/sandboxes/{id}:wake now returns as soon as the sandbox's processes run again. Its clock is corrected immediately after, before any later command for it runs, and the server records the wake with one round of disk writes instead of three. Memory, processes and open files are kept as before.

API requests no longer return controller_standby during a controller release. While Runtime switches its API to a new release, a request that reaches the previous release is held and then served by the new one, instead of returning 503 controller_standby. Such a request can take up to a few seconds longer during the switch; it no longer needs a retry.

App and Function deploys go live, or fail immediately with a clear error. Production now runs the address router and the controller loop that switch an App or Function to a new version and route its address to its copies. Previously a deploy could stay in switching until the next deploy replaced it, and the App's address returned 404. Where that controller is not running, POST /v1/apps/{id}/deploys, /rollback and :restart (and the same Function routes) now return 501 feature_unavailable immediately and change nothing.

Image deploys that cannot start fail with the reason. When the API refuses an image's start command (for example cwd_not_found, because the image's start directory does not exist or cannot be entered), the deploy now fails immediately with deploy_health_failed and that error in lastOutput. Previously it was retried three times and failed with "warming the image stopped 3 times without an answer".

Saving an egress secret returns in under half a second. PUT /v1/egress-secrets/{name}, DELETE, the scope and rules changes, and the upstream proxy calls now return as soon as the change is stored. Each server that runs your sandboxes receives the change at the same time and usually applies it within a second. Previously the call waited until every such server confirmed the change, and took 10 to 26 seconds for an organization with sandboxes on many servers. enforced is true when every server confirmed before the response, and false while one is still applying it.

Status page hosted outside Runtime: status.withruntime.com. status.withruntime.com shows the current state of the API, the website and sandbox creation, measured from six regions outside Runtime's own servers, so it remains available when Runtime or withruntime.com is not. The sandbox check creates the smallest sandbox, runs a command in it and deletes it; a no_capacity response counts as a failure. Each check shows up, down since a given time, or no recent reading, with a 24-hour history, uptime and median latency. The same data is available as JSON at https://status.withruntime.com/status.json. withruntime.com/status links to it.

Snapshots and forks of long-paused sandboxes. POST /v1/sandboxes/{id}:snapshot and POST /v1/sandboxes/{id}:fork no longer return 409 snapshot_unsupported for a sandbox paused long enough for its disk to move to cold storage. The sandbox is restored from its stored copy first (up to 120 s) and is paused again afterward, including when the request fails. A paused sandbox's disk now moves to cold storage one hour after its last use, and only once its stored copy is verified.

A sandbox can run as root by default. Create it with user: "root" (--user root in the CLI, user= in Python, .user("root") in Java, User: "root" in Go), or set it later with :update, and its commands, background processes and terminals run as root, through its passwordless sudo, with no sudo in front of each one. A call can still name user: "sandbox". Forks and copies of its snapshots run as root too; files written through the files API and SSH logins stay the sandbox user's. A sandbox's details include its user. See who you are.

Pagination for secrets. The list action of the runtime_secrets MCP tool now supports pagination with limit (1 to 100) and after, as its schema documents. Pagination is also supported by GET /v1/egress-secrets (pass the response's next value as after to get the next page), secrets.list in every SDK, and runtime secrets ls --limit --after. The runtime_secrets schema now states which action accepts each field, and a field sent to the wrong action returns an error that names the correct one.

Clearer comparison and calculator pages. The pages in the compare and calculators guides use plainer English: shorter sentences and one name for each term. Two figures were corrected: the Blaxel cost in the Daytona vs Blaxel comparison now shows Blaxel's cost instead of Daytona's, and the Runloop vCPU rate on the Runloop alternatives page now shows the published CPU rate instead of a memory rate.

New private networks and dedicated outbound addresses are temporarily unavailable. Creating a private network or reserving a dedicated outbound address returns 503 no_capacity until gateway servers and address pools are added on sandbox servers. Existing private networks and addresses are unchanged. When they return, each new private network is assigned to one gateway server, its endpoint is that server's address, and the organization's sandboxes run on that server; networks and addresses are spread evenly across servers.

Internet off with an allow list reaches the list. A sandbox created or set with network: {internet: false, allow: [...]} was refused every connection (X-Runtime-Egress: internet-off), though its rules showed the list. Internet off with an allow list is now allow-list only: the sandbox reaches the listed destinations and nothing else, and its rules are stored and shown as internet: true with that list, on create and on network.set alike, in the API, every SDK, the CLI, MCP and the console. Internet off with no allow list still reaches nothing. See the network.

A command's record says how it ended. A command whose answer was lost on the way back (its connection cut, or its sandbox stopped or paused under it) is kept as "its answer was lost" (outcome unknown), where it left no record. One still running when its sandbox is stopped or deleted shows ended by the sandbox's stop (or delete), not running for ever. A command that timed out keeps the time limit it ran under. And bwrap (bubblewrap), which Codex runs its commands under, is in the default image from its next build. See commands and processes.

Volume backups go first, and one that can't start says so. A volume backup's copy off its server goes ahead of Runtime's own copies there, never behind one, and copyStartedAt says when it began. A backup whose copy hasn't begun 15 minutes after you asked fails with errorCode backup_stalled rather than staying pending, unless other backups on its server are moving up the line. The volume is unchanged; back it up again. See volume backups.

Pauses, wakes, restarts and stops are in the audit log. Each pause, wake, restart and stop of a sandbox is an audit log entry (resource.paused, resource.woken, resource.restarted, resource.stopped) with who asked; one Runtime did itself says why: it sat idle, it reached its time limit, credit ran out or a spending limit was hit. A volume inside the free 10 GiB, and a job on an account without credit, now read funding: trial, not paid. See the audit log.

Support chat asks you to sign in. The Help chat on withruntime.com is for signed-in accounts: signed out, it asks you to sign in and brings you back to the page, and POST /api/support/chat answers 401. Without an account, write to support@withruntime.com. runtime_support, npx withruntime support and Support in the console are unchanged. See get support.

A sandbox's page in the console loads again. A sandbox's page could fail to load: the server and the browser wrote its chart's and events' dates differently (Sep 23 at 10:30 against Sep 23, 10:30), and the browser threw the page away. Both now write them the same way.

Volume backups on your own schedule. A volume can be backed up every N minutes (15 or more) or on a cron in UTC instead of daily, and keep its backups by counts: the last N, and the newest in each of the newest N hours, days, weeks, months and years. The newest ready backup is always kept. Set it with schedule and keep on the backup policy, in every SDK, the console, MCP, /v1/volumes/{id}:backup-policy and the CLI: runtime volumes backup-policy <id> --every 60 --keep hourly=24,daily=7. schedule: null goes back to daily, and daily and retentionDays work as before. See volume backups.

Sandboxes start from your larger images with no disk to name. A sandbox created from an image of yours larger than the default 4 GiB disk, with no diskMiB, was refused disk_too_small. An image of up to 8 GiB now gets an 8 GiB disk, within the 10 GiB a running sandbox's disk includes, and starts from the image's started copy of that size. A larger image is still refused, now naming the diskMiB to ask for; a diskMiB you name is kept. See images.

Upload links take the 5 GiB they say. An upload link (files:link with method: "PUT") refused a body over 64 MB as too large; it now takes up to its maxBytes, 5 GiB at most, in one request, streamed into the sandbox, with nothing to split. A sandbox can open a file link too, to download or upload with no key. See file links.

The usage export says how far it is final, in every SDK and the CLI. runtime usage export ends by saying on stderr how far the range is final: no more charges will settle before that time. The Python, Go, Ruby and Java SDKs gain the export (usage_export, UsageExport, usageExport), with finalThrough on each page and final on each row. See export settled usage.

E2B's client works in the drop-in. new E2B({ apiKey }).Sandbox in JavaScript, and now E2B(api_key=...).Sandbox in Python, create and connect with the client's key. The client's Template, Volume and Secret refuse before anything happens, naming what to use instead: a Runtime image, Runtime volumes or a Runtime secret. See migrating.

Previews are never indexed. Every answer on a preview address, private or public, carries X-Robots-Tag: noindex, nofollow, and each preview address serves Runtime's own robots.txt, so no preview shows up in search. A custom domain serves your site's own headers and robots.txt; use one for a site that should be found. See search engines.

First in line by plan when room is short. When a region is short of room, the room that frees goes first to the highest lane waiting for it: Enterprise, then Scale, Pro Max, Pro and Free, from the account's plan, and Runtime's own work after every customer's. Until an account chooses a plan, paying accounts go before trials. A create or wake refused no_capacity keeps its place while it is sent again with the same Idempotency-Key, as the SDKs do, and the refusal says its place, how many wait ahead and its lane, also in details.line. Nothing already running is stopped for a higher lane. See waiting in line for room.

A slow upload is given the time to arrive. A request's 110 seconds to answer now start once its body has arrived, so a chunk of a large upload over a slow or busy link is no longer cut while its bytes are still coming in, and answered 503 api_unavailable as if the API were at fault. A body may take up to about 280 seconds to arrive. One still arriving after that is answered 408 request_timeout with the bytes received so far; the SDKs and the CLI get 503 body_stalled and send it again by themselves. Many uploads at once over one slow link share it: send fewer at once. See files.

30 days to top up. When credit runs out in an account that has bought credit or saved a card, its stopped and paused sandboxes' disks are kept 30 days, not seven, with a notice first and a warning the day before, and adding credit in that time keeps them. Other stored items, and every item in an account that has done neither, keep their seven days. See when your balance runs out.

A scheduled job keeps data between runs on a volume. A job's compute.volumes attaches up to four of your volumes to every run, each at a path, as a sandbox create does: read-write, one run at a time, so each run reads what the last one wrote, or a read-only snapshot copy. In the CLI, runtime jobs create ... --volume <id>:/data, and for a job you already have, runtime jobs update <job> --volume <id>:/data or --no-volumes; in the SDKs' next release. A run that waits for its volume says so with blockedReason volume. See Keep data between runs.

A full region answers 503, and an account at its limit 429. No room for a sandbox, a fork, a restart, a wake, a build or a volume, no_capacity, is now 503 Service Unavailable with Retry-After: 1. The account at a limit on what runs at once, quota_exceeded or no_credit_running_limit, is now 429 Too Many Requests with Retry-After: 5. All three were 409 Conflict, which a client that retries only 5xx and 429 gave up on. Such a client now retries them with no change. The body is the same, so code that reads error.code keeps working. In the SDKs' next release the error's class follows the status: no_capacity is a ServiceUnavailableError, and the two limits are a RateLimitError, not a ConflictError. The SDKs still wait them out on create, wake and restart, and return them at once elsewhere, as before. See errors.

Every error says whether to retry it, and its status means what HTTP says. Each error now has retryable, true or false; a retryable one always carries a Retry-After header, and no other does. Each code has one status, listed with every code in Responses and errors and in the OpenAPI document's x-error-codes. Codes are unchanged, so code that reads code keeps working; a check on the status may need a look:

• 409 is now only a state you change first, or one that clears by itself (snapshot_not_ready, image_not_ready, volume_releasing, ... are retryable).
• Your own limits that clear by themselves are 429, always with Retry-After: quota_exceeded on what runs at once (details.limit such as sandbox.count or sandbox.memory_mib), the no_credit_* limits on what runs, process_limit, transfer_limit, guest_busy, build_in_progress and the daily caps.
• A count that falls only when you delete something is 409, with retryable: false and no Retry-After, so no retry library retries it: no_credit_kept_limit, limit_reached (keys, invitations, compartments) and quota_exceeded on what is kept (volumes, snapshots, images, secrets, sandbox.kept). Delete one, or raise the limit.
• A full region or host is 503 with Retry-After: no_capacity, host_capacity, own_share_full.
• A product switched off on a deployment is 501, not 503, so no client retries it.
• A fault of ours that a retry does not fix is 500 (operation_failed, price_unavailable, and watch_failed: Runtime's own file watcher in a sandbox); a service behind the API is 502 or 504.
• A request that cannot be done as asked is 422: disk_too_small, idempotency_conflict, no_credit_size_limit, a program in your sandbox that failed (interpreter_failed, tunnel_unavailable).

The SDKs read retryable (in the same versions). They retry an answer that says retryable: true after its Retry-After, and never one that says false. A create, wake or restart waits out room and the account's limits for its own wait for room (two minutes by default; 0 returns at once), and a fork returns them at once. An answer whose wait is over a minute (a daily cap) is returned at once, with retryAfterMs. The Go, Ruby and Java SDKs now also resend a call refused guest_busy, busy or rate_limited until its deadline, as JavaScript and Python do. The CLI's --json errors carry retryable and retryAfterMs.

Accounts without credit hold up to 10 API keys. A new key past ten is refused with no_credit_key_limit (409) and says how to make room: revoke a key you no longer use, or add credit, after which there is no limit. Every key an account already holds keeps working, and keys Runtime makes for the console, its terminals and image builds are not counted. See free usage.

runtime.apps in the TypeScript SDK, for the Apps private beta. withruntime's next release (npm i withruntime@latest) has runtime.apps: create an App, deploy an image to it, follow the deploy, roll back, and list its versions and copies. Apps is a private beta for now: an account outside it gets product_in_beta (403), with a hint to ask support to join.

Book room for a burst. Book room for up to 10,000 sandboxes of one size for a window of up to 24 hours, starting now or within 14 days, and be told at once whether you have it. In the window your creates are never refused no_capacity or quota_exceeded up to what you booked; sandboxes you run bill as usual. A decline says why, the most that fit and the nearest window that takes them all. In the API (POST /v1/reservations), the JavaScript, Python, Go, Ruby and Java SDKs (runtime.reservations), the CLI (withruntime reservations book) and MCP. See Book room for a burst.

Booked room left unused costs a little. Room a booking holds that none of your sandboxes uses now costs a quarter of the memory rate, $0.001875 per GiB-hour, with no CPU charge; sandboxes you run bill as usual. 300 sandboxes of 2 GiB booked for 2 hours cost at most $2.25 if none run, and nothing if you cancel at least an hour before the start. A booking's answer, the CLI and the console's Booked room card say the most it can cost. See What it costs.

Standing room for a pool. Keep room for a pool of sandboxes until you cancel it: name the snapshots it forks from and the room is held on the servers holding them, so a sandbox replaced after each use is never refused for room or limits. forKey keeps it for one key's sandboxes, and inUse says how much of it runs now. Room none of them uses costs a quarter of the memory rate, $0.001875 per GiB-hour. See standing room.

Audit log entries older than 400 days are now removed. The audit log has always promised to keep each entry for at least 400 days; until now it kept every entry forever. From this release, entries past 400 days are deleted, oldest first, and none younger is ever touched. See the audit log.

Node trusts HTTPS from a sandbox's first command. A sandbox with egress secrets checks its HTTPS with Runtime's own certificate authority, and Node, which keeps its own roots, learns it from NODE_EXTRA_CA_CERTS. A sandbox's or a scheduled job's first commands, in its first few seconds, could start without that variable, and Node refused every HTTPS call with SELF_SIGNED_CERT_IN_CHAIN. They now have it from the start. See networking.

The CLI says when a certificate is not trusted. Behind a proxy or firewall that inspects TLS with its own authority, every call failed as "No answer from Runtime". It now says the certificate presented is not one your machine trusts, with its code, and to point NODE_EXTRA_CA_CERTS at the proxy's certificate.

runtime images build -f reads the Dockerfile as docker build does. runtime images build . -f apps/web/Dockerfile builds a monorepo's app with the repository as its context: -f is read from where you run the command, and a path inside the folder still works. See images.

Apps and Functions: what Cloudflare's cache serves is outbound traffic (private beta). Once Cloudflare's cache serves Apps and Functions, the bytes it serves for an App's or a Function's addresses and custom domains, without reaching it, are charged as outbound traffic, the same as a sandbox's: from the account's 100 GiB a month free first, then $0.02 per decimal GB. They are read from Cloudflare's analytics an hour at a time, charged once per hour, and shown in GET /v1/usage under outbound. An App or Function made without credit sends for free and uses none of the allowance.

Storing several secrets at once no longer fails. Writing egress secrets (PUT or DELETE /v1/egress-secrets/{name}) or the upstream proxy from parallel jobs of one account used to fail with 503 busy for all but one of them. Now the writes wait in line and each one succeeds. See the API.

Sandbox desktop, browser, MCP servers and mounts in the console. A sandbox's page now lets you open its desktop and watch it live, record it, start or stop its browser, and see or stop its code contexts, MCP servers, bucket mounts, file watches and tailnet, each stop asked first. Networking gains the switch for your sandboxes to reach each other by name.

Faster website on phones. Pages on withruntime.com no longer download two extra font files, 140 KB, to look for a single character such as "10⁹" or "✓": the home page loads about a third lighter on a phone, and the pricing, comparison and blog pages about a fifth lighter. See pricing.

Clearer page titles in search results. Guides now show titles that say what they cover, such as "Python SDK for agent sandboxes" or "Custom sandbox images from any Dockerfile", so they are easier to find. See the Python SDK.

CI/CD leaves no run "Waiting" on GitHub after its check ended. A check restarted midway, or one whose tests were split into a different number of parts, could leave old runtime / … runs queued or in progress on the commit for good, though the check itself had passed, failed or been cancelled. Within a few minutes of a check's end, every run of it GitHub still shows open is now ended: a job's run with its job's result, an extra runtime run with the check's own, and a run of a job the check no longer has as Cancelled, "Not run: its check ended before this run of the job began." Another check of the same commit keeps its runs as they are.

A CI/CD check that can no longer finish now fails, with the reason. Before, a check whose runner stopped, or whose job hung, could show "in progress" on GitHub for hours. Now it fails within minutes of the point it can no longer finish, saying why: a job sent nothing for longer than its 30-minute limit, no machine came for its jobs in 45 minutes, no runner has held it for 30 minutes, or it waited an hour to start. Re-run it on GitHub to check the commit again.

Choose what happens when an App release gets worse (private beta). An App or Function now has releaseWatch: when a new version's errors or speed get clearly worse in its first 15 minutes, alert (the default) tells the account's owners, rollback also goes back to the previous version by itself, and off does neither. Each release judged worse posts an app-release-worse notice to GET /v1/notices for every owner, shown on Usage & billing and emailed to them. Set it on create or update from the API, the MCP tools, or the JavaScript 0.24.0, Python 0.22.0, Go 0.11.0, Ruby 0.10.0 and Java 0.10.0 SDKs. Only an account-wide key made on the website turns it off: a key in a compartment, a key made by another key and a sandbox's own session key may choose alert or rollback, and off is refused with 403 forbidden (compartments, run a swarm).

A job tells you when it fails, runs your image, and changes in place. A job's alert posts to your webhook, signed with a jobs secret, or emails you once runs fail in a row, with the run's reason, exit code and last lines of output, and once more when a run succeeds again. Your account's webhooks hear job.run.failed and job.recovered. --image starts each run from an image of yours, and runtime jobs update (PATCH /v1/jobs/{id}) changes a job's command, image, size, secrets, alert, timeout or retries and keeps its history. In withruntime 0.29.0 for JavaScript and the CLI, and 0.28.0 for Python. See alerts.

Every App has a readable address (private beta). Every App and Function, those you have and every new one, answers at its name, 16 random characters, then its account's handle: https://shop-3f9a1c2e7b04d915-acme1.runtimehost.com/ for the App shop of the account Acme, in url on the App and its deploys, in the API, the console and every SDK. It is kept for life: a rename leaves it, and a handle is never another account's, even after an account closes. Every App keeps its id's address too.

A disk snapshot of a sandbox that is writing no longer fails. A mode: "disk" snapshot of a running sandbox used to fail with "could not confirm that its writes reached its disk" whenever a program in it was writing. Its pause now waits for the sandbox to write out what it still held in memory before the snapshot is taken. That takes milliseconds when the sandbox is quiet and can take a few seconds while it writes. Memory snapshots are as fast as before. See the API guide.

A trust center for your security review. withruntime.com/trust gathers what a security team asks a vendor for on one page: the public documents, where data lives, how sandboxes are kept apart, encryption, sign-in, availability and recovery, every subprocessor, and how to report a vulnerability. A filled-in questionnaire is on request from security@. See security and compliance.

GitHub App tokens, push limits and API budgets for secrets. A secret can now hold a GitHub App's private key (githubApp): our servers make its installation tokens and add them to your sandboxes' GitHub requests and git pushes, and the key itself goes into no request. git.push names the branches a push may update, such as refs/heads/task/{label.task}: each label's branch belongs to the first sandbox made with it, even once it is deleted, and that label can't change after the sandbox is made. Any other push is refused with git's own [remote rejected], as is any API call that would move, merge or write to another branch. api caps each sandbox's calls and writes an hour, lists the GraphQL mutations allowed, and lets sandboxes share cached reads. A rule's path segment that is * alone now names any one segment. See GitHub: an App's tokens, branch limits and API budgets.

SDKs take a secret's GitHub App, push limits and API budgets. withruntime 0.25.0 for JavaScript and 0.23.0 for Python, the Go SDK 0.12.0, and the Java and Ruby SDKs 0.11.0 set and return githubApp, git and api. See GitHub: an App's tokens, branch limits and API budgets.

Clear refusals instead of 500 errors on sandbox create. A create that asks for ports beyond 80 and 443 (network.connect) from an account without a kept top-up is refused with 403 connect_not_allowed, saying what lifts it, and a maxTotalCostMicros below the first minutes a paid sandbox holds is refused with 400 invalid_request naming that field; both answered 500 before. A pause sent while a sandbox is still starting, a wake sent while it is pausing, and a restart sent while it is stopping now wait for it instead of being refused, and a file call right after a wake waits for the sandbox to listen instead of answering guest_busy. A persistent sandbox stopped before it ever started now reads diskKept: false, since it has no disk to restart from; it read true, and its restart was refused. See networking, limits and the API guide.

API key limited to chosen sandboxes, approved in the browser. An agent with no key can now ask for a key that reaches only the sandboxes it names, whichever key or connector made them: runtime keys create --sandbox <id> --actions get,exec. An owner or admin approves it from a link, seeing each sandbox and what the key may do. Without create it cannot start, wake or restart them; a running one is billed as usual until its own time limit. See asked for in the browser.

Snapshot starts no longer stop for CPU on one server. A sandbox started from a snapshot whose server was short of CPU for your other sandboxes used to stop with account_busy_here. Now it starts on another server that holds a checked copy of the snapshot, and stops only when none of them has room (or after it has moved 3 times). See A sandbox stopped on its own.

Apps console with traffic and live releases. Console → Apps shows each App as a card with its last day of requests, error rate, copies running, last release and this month's cost. An App's page draws its copies by version, a release step by step as requests move to the new version, its requests, errors and latency over an hour, a day or a week, its busiest routes, and log search by request id or any words. A failed release keeps its output, and the previous version rolls back in one click. See custom domains on an App.

Move from Cloudflare Sandbox to Runtime. A Worker written for Cloudflare's Sandbox SDK (0.x) now runs on Runtime sandboxes once you change its import to withruntime/cloudflare, delete the containers block from wrangler.jsonc and add a RUNTIME_API_KEY secret. Commands, streaming, files, background processes, the code interpreter, preview URLs, sessions and gitCheckout work as before. See change the import.

A sandbox can name the secrets it gets. Create a sandbox with secrets: ["ANTHROPIC_API_KEY"] (runtime sandboxes create --secret ANTHROPIC_API_KEY) and it gets only that egress secret: no placeholder for any other, and our proxy puts no other value into its requests. An agent given untrusted input can no longer send a key meant for other work. [] is none; the list narrows each secret's own only, is fixed for the sandbox's life, and a fork or copy of a snapshot may only narrow it. In the API, the MCP tool and every SDK. See secrets sandboxes never see.

One deletion email a day, not one per pause. A sandbox with :retention days of its own is a day or so from deletion after each idle pause, and its owners were emailed a warning on every pause, though using it again cancels the deletion. Warnings for dates you set this way are now emailed at most once a day for the account, listing every sandbox due, and never once a sandbox has woken or paused again since; the email says its own retention chose the date, and null keeps it while you have credit. See pricing.

A secret that could not be added is no longer silent. When a request to a secret's host leaves your sandbox without the secret because our server could not add it at that moment, the sandbox now gets a sandbox.secret_not_applied event with reason withheld, saying the fault is ours and what to do. See events.

A worker's key runs its own Apps. A key made by another key, or a key in a compartment, can now create, list, deploy, roll back and delete the Apps and Functions its own agent made, as it does sandboxes, over the API and MCP. Another agent's App still answers 404. Such a key deploys from an image only: a deploy naming a build answers 403 (forbidden, or outside_compartment in a compartment); deploy builds with an account's key. Such a key asks an App for at most 2 minCopies, 2 spares and 20 maxCopies; a larger App is made with a key made on the website. It cannot give an App or Function a name one of the account's own Apps holds: create or rename answers 409 name_taken. See Run a swarm.

MCP: runtime_apps action deploy takes its id. It refused its own id, and listed no image or build, for every key; it now takes them. The runtime_apps tool also answers a worker's or compartment's key in the Apps beta, which it refused before.

Snapshots and forks in bursts no longer wait running. A snapshot or a fork of a running sandbox now stops it at once, so the snapshot, or the fork's copies, hold the memory of the moment you asked, and then waits for its turn at the server's disk with the sandbox stopped. Before, it waited for that turn with the sandbox still running, and a burst on one server could take tens of seconds each, the sandbox changing all the while. A sandbox whose time limit or funded time ends soon, on a busy server, still waits running and stops at its turn, as before. See products.

Secret scopes in the Python, Go, Ruby and Java SDKs. The SDKs can now give a secret to some sandboxes instead of all of them, as the JavaScript SDK can: only on secrets.set (only= in Python and Ruby, Only in Go, a sixth argument in Java) and secrets.scope(name, only) (Scope in Go), which changes who gets an existing secret without its value. Python is 0.17.0, Go 0.6.0, Ruby 0.5.0 and Java 0.5.0. See

Give a secret to one App's copies. runtime secrets scope NAME --only-app <app id> gives a secret to every copy of an App, including copies later deploys, restarts and scaling make; a deploy names the secrets its copies see with secrets: ["NAME"], and a copy holds only the placeholder. An App copy's identity token now says which App it is (app_id). See secrets sandboxes never see.

A sandbox out of memory still answers. When a sandbox's programs fill its memory, Linux now ends one of them for memory, as the guide says, instead of the whole sandbox slowing until commands, reads and kills time out. Your programs share its memory less a small reserve for the sandbox's own services. See when a program runs out of memory.

Upload stalled: a clear answer in 30 seconds, not a 503 after two minutes. A request whose body stops arriving for 30 seconds, such as a chunk of a large upload, is now answered at once with the bytes received, where before it waited about two minutes and answered 503 api_unavailable. A body that keeps arriving, however slowly, is never cut. The SDKs and the CLI get 503 body_stalled and send it again by themselves with the same key; other clients get 408 request_timeout. See errors.

Fetch a web page in under a second with a paused browser. The guides show how to keep spare browsers paused, charged only for storage, and wake one per page: wake to page done measured 0.56 to 0.81 seconds. Python's guide gains its browser section. See Spare browsers, paused.

Connection limit per site: 429 Too Many Requests from the egress proxy. A sandbox opens up to 20 new connections a second to one site, and an account's sandboxes on one server up to 100 together, after a burst. Past it the connection is refused with 429 and a sentence naming the site. Downloads over open connections, installs, clones, storage, CDNs and AI APIs are never counted. See connections to one site.

Identity tokens from any running sandbox. A program with no RUNTIME_ID_TOKEN_REQUEST_* variables, such as one started before they were set or a sandbox kept from older guest software, now gets a token too: Sandbox.identityToken() (TypeScript 0.17.3), Python's Sandbox.identity_token() (0.16.2) and runtime sandboxes identity-token ask the sandbox's host for them, and the docs show the same with curl alone. See identity tokens.

No 429 for a busy key right after an update of Runtime. A key whose account runs many sandboxes may send up to 8 times the ordinary rate. Just after Runtime updated its servers, its first requests met the ordinary rate instead, for the moment it took to recognise the key, so a burst sent then was answered 429 rate_limited. Those requests now wait that moment, at most two seconds, and are served at the key's own rate.

Daytona's GPU and sort enums import from the drop-ins. The Daytona drop-ins follow Daytona 0.225.0 and the Prime Sandboxes one follows 0.4.6. GpuType, SandboxClass and the list sort enums now import from withruntime/daytona and withruntime.daytona, and the sort enums sort list. A Python create that asks for a GPU type now gets a plain error, as TypeScript already did, instead of a CPU sandbox. Prime's new lan_network_id on create is refused before a sandbox is made, naming Runtime's private network. See Migrate.

Idle sandboxes now pause after 5 minutes. A new sandbox, browser or sleeping container pauses after 5 minutes with nothing happening in it by default, where it was 1 minute before. Rates are unchanged, but an idle sandbox that sets no idle time now runs, and is billed for its memory, up to 4 more minutes before it pauses; set idlePauseSeconds to 60 to keep the old default. The shortest idle pause is now 60 seconds, not 10: a time of 10 to 59 seconds you set on a new sandbox, or change to, is raised to 60, so that sandbox runs, and is billed, until 60 seconds idle. The answer shows the 60 it got; 0 still turns pausing off. Sandboxes made before today keep the setting they have, under 60 too. See pause when idle.

100. A declined charge turns it off and never stops a running sandbox. Also runtime billing auto-top-up, the SDKs and /v1/billing/auto-top-up. See auto top-up.

50. Paused and stopped sandboxes no longer count toward it, and an account keeps up to 1,000 in all. A time limit goes up to 24 hours, where it stopped at one, and a sandbox it stops reads stopReason time_limit where it read lease_expired, in the API, events, webhooks and OpenTelemetry export: code that compares with lease_expired should compare with both. A sandbox's disk is at most 400 GiB, and a larger diskMiB is refused at once, naming the limit. See how many at once.

100. with no card.