Runtime changelog, 17 October 2026
What shipped in Runtime Cloud on 17 October 2026: browser starts in about 1 to 2 seconds in a new sandbox; give a sandbox a key without typing it into a command; swarm worker keys cannot reach scheduled jobs or their secrets; a revoked worker's spend still counts against its maker's limit; run commands as root; keys limited to sandboxes; wake and restart wait for room; API rate limit grows with your sandboxes; paused sandboxes keep their memory when many pause at once; console pages no longer hang; relabelling a sandbox into a secret's scope takes effect at once; a job run that reaches its timeout ends as a timeout; and FUSE filesystems.
Browser starts in about 1 to 2 seconds in a new sandbox
The browser now comes ready on the sandbox's host instead of being downloaded and installed on its first start, which took up to a minute: browser.start() in a brand-new sandbox now returns in about 1 to 2 seconds. A custom image that is not Ubuntu 24.04 x86_64 still installs it once on its first start (withruntime 0.17.2, and 0.16.1 for Python). See A browser over CDP.
Give a sandbox a key without typing it into a command
In the CLI, --env NAME with no = sends that variable's value from your own shell, as docker run -e NAME does, on create, update, exec and run (withruntime 0.17.1). The security guide now shows how to install a key your sandbox's server checks on incoming requests, and the same key at another provider, and how to rotate it with no failed request. See Shared keys.
Swarm worker keys cannot reach scheduled jobs or their secrets
A key made by another key with reach agent now gets 403 forbidden on /v1/secrets, /v1/jobs and /v1/job-runs, and on the runtime_jobs and runtime_secrets_jobs tools, as the guide already said for secrets: a job's secrets belong to the person the key's agent serves, often the owner. See Run a swarm.
A revoked worker's spend still counts against its maker's limit
A key revoked, expired or retired counts what it spent in the last day toward the daily limit its maker's keys share, so revoking a worker that spent its limit and making another no longer spends that limit twice.
Run commands as root
A command, background process or terminal now takes user: "root" and runs as root, with its environment, PATH and working directory kept and HOME set to /root, so nothing needs a sudo in front. The default is still the sandbox user, runtime, and each process says which it runs as. It is in the API, MCP, the JavaScript, Python, Go, Ruby and Java SDKs, and the CLI (--root on exec, spawn, run and shell). Coming from Freestyle, whose VMs run as root? See how to switch.
Keys limited to sandboxes
A key can now be limited to a few sandboxes and to what it may do to them: look, start and restart, stop, run commands, or reach files. It is served nothing else, so a watcher that restarts one server holds no key to the rest of your account. Make one with runtime keys create --sandbox <id> --actions get,create, or sandboxes and actions in POST /v1/keys and runtime.keys.create. See Teams.
Wake and restart wait for room
In the JavaScript, Python, Ruby, Go and Java SDKs, a sandbox's wake and restart now wait for room as create does. When the sandbox's own server is full (no_capacity), the SDK sends the call again with the same idempotency key, for up to two minutes by default, instead of failing in a few milliseconds. A sandbox stays on its server, so waiting is the only way it gets room. Set waitForCapacityMs (JavaScript) or wait_for_capacity (Python, Ruby) on one call; 0 fails at once. A fork never waits. See JavaScript.
API rate limit grows with your sandboxes
An API key's rate now grows with the sandboxes its organization runs, as its requests in flight already did: about 170 requests a second in bursts of 675 with 40 sandboxes, up to 400 a second in bursts of 1,600. Before, every key stayed at 50 a second however many sandboxes it drove, so one key running dozens of agents was answered 429 rate_limited for much of its work. See Limits.
Paused sandboxes keep their memory when many pause at once
A sandbox told it was paused is now written to disk early enough even while many other sandboxes on its server are pausing too. Before, one could wait too long behind them, and wake from its disk alone with its memory lost. See pause and wake.
Console pages no longer hang
A console page whose data the database is slow to give now stops within 15 seconds and shows "This page did not load" with Try again, where it could spin for minutes. Nothing you run is affected. See troubleshooting.
Relabelling a sandbox into a secret's scope takes effect at once
Changing a running sandbox's labels so a scoped secret reaches it (or no longer does) now waits until its server holds the change, and the answer carries secretsEnforced: true (for a key that may read secrets; any other key's relabel takes up to 15 seconds, as before). Before, requests could go out without the value for up to 15 seconds after the label call returned. See Security.
A job run that reaches its timeout ends as a timeout
A run whose timeout was as long as its paid time (a one-hour timeout, say) ended unknown or canceled with the reason compute_stopped when it ran to the end, with no exit code and no retry. It now ends failed with the reason timeout, keeps its exit code and output, and is retried when the job asks for retries. See jobs.
FUSE filesystems
sshfs, rclone, s3fs, gcsfuse, bindfs or your own FUSE program mount in any sandbox as its own user, and a mount lasts through a pause and a wake. See FUSE filesystems.