Fly Machines API on Runtime
Code written for Fly's Machines API now runs on Runtime by changing one address: run npx withruntime fly-api and point FLY_API_HOSTNAME (or fly-go's FLY_FLAPS_BASE_URL) at it. Each Machine is a sandbox; init, env, files, metadata, leases and the restart policy work, and what isn't supported is refused with Runtime's alternative. Node services can serve it themselves with machinesApi() from withruntime/fly. See switching from Fly Machines.
Every router serves the same routes, and a copy stops only once none sends it visitors
An App's or a balancer's change counts served only once every Runtime router serves it, so a deploy's old copies stop only after no router can still send them a visit. A router that has never had its route table yet answers router_not_ready (503, Retry-After: 1) instead of no_route. See Networking.
Functions in the CLI and the console (private beta)
runtime functions creates, deploys, lists, reads, updates, rolls back and deletes Functions, and lists their releases, versions and copies, as runtime apps does for Apps. In the console, Functions has a list of its own beside Apps, and each Function a page with its calls, errors, releases, copies and logs, with deploy and rollback. Outside the beta these are refused with product_in_beta. See the CLI.
Snapshots kept while you have credit have no end date
A snapshot taken without retentionDays used to be deleted a year after it was taken, even with credit on the account. Now it is kept for as long as you have credit, as the 4 October entry said. See pricing.
The Vercel-compatible snapshot's expiresAt
For a snapshot kept while you have credit it now reports a year from now, moving on with each read, instead of a year after the snapshot was made, a date that would pass while the snapshot was still kept. In the JavaScript SDK's next release.
The data processing addendum, privacy policy and subprocessors page say more, and say what is true today
A new subprocessor is listed at least 30 days before it starts, and you may object within those 30 days; email legal@withruntime.com to be told when the list changes. A breach affecting your data is reported to your account's owners within 72 hours, with what happened, who and what it touches and what we are doing. Closing an organization destroys its key first, then deletes its data, and the addendum gives every step's time limit, including each server's own nightly backup, gone within 44 days. Once we hold a SOC 2 report, it is shared under a confidentiality agreement as our answer to audit requests. The addendum lists the security measures we run now. Anthropic, which runs the AI model that answers support, and Slack, which carries our team's alerts and support drafts, are now on the subprocessors page. See security and compliance.
Keep-alive ends when its sandbox is deleted
In every SDK, a sandbox's keep-alive (keepAlive, keep_alive, KeepAlive) now ends at the first answer that the sandbox is gone, as when it was deleted by id from another handle or another process. Before, it went on reading the deleted sandbox once a minute for as long as the program ran.
Storage is limited in GiB, not only counted
An account keeps up to 500 GiB in all with credit (50 GiB without): snapshots, images, volumes, volume backups and paused or stopped sandboxes, measured as they are billed; snapshots up to 250 GiB of it (20 GiB without). Past a limit nothing is deleted or stopped: a new snapshot, image, backup or volume is refused with quota_exceeded, naming the limit, until there is room. An account that already stored more than a limit when it began has what it stored then as that limit. Both are on the Limits page and in GET /v1/limits. See limits.
Requests in flight grow to your sandbox quota
An account's requests in flight grew by six for each sandbox it holds only up to 1,024 (138 sandboxes). Now an account whose sandbox quota support raised past 138 keeps growing, six for each running sandbox up to that quota: 2,592 for 400 running, so each can stream four commands and two watches at once. Watch streams, SSH logins, port forwards and terminals grow with it. See limits.
A command may run 15,360 processes and threads
One command and everything it starts may hold up to 15,360 processes and threads together, of a sandbox's 16,384; it was 1,024. Test runs that start many processes, Java and parallel builds on a sandbox with several vCPUs no longer fail to start a thread. A sandbox gets it the next time it starts; a custom image, once it is built again. See limits.
Started copies are kept for images in use
A server keeps an image's started copies (the ones a sandbox starts from in about half a second) while sandboxes are created from that image there. Once none has been for 2 days, the copies go. The first sandbox after that gap boots the image (a few seconds), and the ones after it start from copies again. Before, every image version kept its copies on every server it reached, used or not. See Images.
See which files a command read
Run a command with traceFiles: true and its answer lists every file and folder it, and anything it started, opened, and every file it wrote; other programs on the sandbox never show up. Key a test cache by those files and rerun only the tests whose files changed. Background processes, every SDK and runtime sandboxes exec --trace-files have it too. See commands and processes.
A paying account's stopped sandboxes keep their disk 30 days
When a sandbox stops to clean up (a stop from an older client, the end of its time limit, or a crash), an account that has paid, holds credit or saved a card for automatic top-ups now keeps its disk free for 30 days after the stop, not three. Disks already waiting in such an account move to 30 days from their stop, never less than a day from now, and you get the deletion notice again before the new date. Other accounts keep three days. See paused storage.
Turn an App's CDN off (private beta)
Cloudflare's CDN sits in front of every App's and Function's addresses by default, with no separate fee. Set cdn to false when you create or update one (--cdn off in the CLI, cdn in the API, MCP tools and every SDK) to send visitors straight to Runtime's routers, with nothing cached.
Read and follow an App's logs (private beta)
What an App's or a Function's copies print to standard output and error is kept 14 days and read back with GET /v1/apps/{id}/logs (/v1/functions/{id}/logs), the runtime_apps_logs and runtime_functions_logs MCP tools, runtime apps logs <app> in the CLI, and logs in every SDK. Narrow it by since (a time, or 30s, 15m, 2h, 7d; an hour by default), version, copy and stream; page back with cursor. With follow it streams each line as it is printed, and the SDKs and the CLI reconnect by themselves and give each line once. A key that may read files reads the logs of the Apps it can see, a worker's or a compartment's key its own Apps' alone. Outside the beta these calls are refused with product_in_beta.
Sandboxes with egress secrets start under heavy load
Creating a sandbox that names its egress secrets (secrets) checks its list again rather than failing at once with secrets_unconfirmed when the service is busy, and one account sending far more requests than its limit is slowed alone while other accounts' calls go through. See Keys and secrets.
Request timeouts on sign-up and webhook routes
A request to a route you call before you have a key (the MCP sign-up, GitHub's webhooks and install link, and an agent's reports) whose body has not all arrived after 5 seconds is now answered 408 request_timeout straight away: send it again. Before, it waited 15 seconds or more and was answered 503 api_unavailable as if Runtime had failed. See errors.
The Prime Sandboxes drop-in follows 0.4.7
Code written for prime-sandboxes 0.4.7 runs on withruntime.prime. Its new arch option on create works with "amd64", and "arm64" gets a plain error before any sandbox is made, as Runtime sandboxes are x86-64. create_lan_network now takes rules and, as before, names Runtime's private network instead. See Migrate.
Workers start from their coordinator's snapshots
A key made by a key can now create a sandbox from a snapshot that its maker, or any key above it, took and labelled share: made-keys. It can only start from it: it never lists, reads, changes or deletes it, and a snapshot without the label stays out of its reach. The label is never copied to sandboxes, forks or new snapshots made from a shared one: set it on each snapshot you share. Worker keys made before this release need to be made again to use it. A share: made-keys label already on a snapshot was taken off, so nothing became shared by itself; a share label of any other value is untouched. A snapshot of a sandbox that named its egress secrets (secrets) is never shared: workers get snapshot_not_found for it, while its owner still starts it. Sharing never crosses a compartment. Before, a worker key with reach agent was answered snapshot_not_found for every snapshot but its own. See Run a swarm.
A scraping account no longer gets other accounts blocked
Runtime can move an account whose sandboxes scrape sites to outbound addresses kept for scrapers, so a site that answers it with a CAPTCHA or a ban does not block the other accounts on the same server. The move reaches its running sandboxes at their next connection, they keep their internet throughout, and the addresses are in the same published list as the shared ones. See Shared addresses.
MCP sandbox switch and resize refusals say what to do
Through MCP, switching a sandbox's image while asking to keep more than /workspace again says what a switch keeps and how to keep everything (snapshot first), and a resize sent without a restart says that a resize always restarts, instead of naming only the field. See MCP.
Jobs secrets belong to the key that stored them
A jobs secret stored by an API key can now be used only by that key, by agents you name, and by you. Share it with your other keys using runtime secrets share NAME --agent <id>, --all or --none (secrets.share in the SDKs, POST /v1/secrets/{id}:share). Secrets you store on the website stay every key's. A job that binds a secret another key stored stops at its next run until that key or you share it; if another of your keys could reach a secret before now, rotate it. A job created with a secret its key may not use is refused with secret_not_shared. See secrets in a job.
Ask support to stop our emails and get a straight answer
Email support "remove me from your list" and the support agent now tells you which of Runtime's emails reach that address, if any, and how to stop each: the link at the foot of each optional email, or Settings, Emails in the console. It no longer passes the request to a person or promises a removal. See Stopping Runtime's emails.
Raise how many sandboxes run at once
Ask support for a higher count and it is raised for your account with the vCPUs, memory and disk to match, never below what auto top-up gives, whether auto top-up is on or off. See when you meet one.
A sandbox paused for abuse stays paused until support lifts it
When the abuse checks pause or stop a sandbox for traffic only abuse makes, such as reaching a cryptocurrency mining pool, a wake, restart, snapshot or fork of it now answers sandbox_halted (403) saying why, instead of running it again. Its files are kept, and your inbox says what was seen. See Security.
A build on a busy server waits for room instead of failing
When the server an image builds on has no room for its build machine at that moment, the build waits up to five minutes for room and then runs, and its log says it is waiting. Before, it failed at once with a fault on our side and asked you to build again. See Images.
Narrow a secret without its value
runtime secrets set NAME --keep-value with a narrower --host or --allow takes hosts, methods or paths away from a secret you stored, with no need to have its value at hand: a token that could push to a repository can be made fetch-only by anyone who may write secrets. Anything wider is refused, since a new place could learn the value. In the API, PUT /v1/egress-secrets/{name}/rules; in every SDK, secrets.narrow (withruntime 0.22.0 for JavaScript, 0.21.0 for Python); in the console, leave the value empty when you edit a secret to take hosts or rules away. The audit log records each one. See Secrets sandboxes never see.
Links to one file in a sandbox, with no API key
files:link (API), sandbox.files.downloadUrl and uploadUrl (JavaScript, with download_url and upload_url in Python, and the same in Ruby, Go and Java) and runtime sandboxes link make a secret, expiring URL for one file. A GET downloads it (Range works, so videos play and downloads resume); a PUT writes it atomically, up to 5 GiB. A link lasts 1 hour by default and at most 7 days; revokeLinks ends every link of a sandbox, and revoking the key that made one, or deleting the sandbox, ends it too. E2B's downloadUrl and uploadUrl now work the same way. JavaScript 0.25.0, Python 0.23.0, Go 0.12.0, Ruby 0.10.0 and Java 0.10.0. See files in the API guide.
Apps, Functions and Builds in the Go, Ruby and Java SDKs (private beta)
Go 0.7.0 (client.Apps, client.Functions, client.Builds), Ruby 0.6.0 (client.apps, client.functions, client.builds) and Java 0.6.0 (apps(), functions(), builds()) carry every method the TypeScript SDK has: create, deploy from an image or a build and wait for it, roll back, versions and copies; builds of a connected repository with their log, followed as it is written. Each can also ask for the link that installs Runtime's GitHub App, so private repositories build. Outside the beta these calls are refused with product_in_beta.