Skip to content

Changelog

20 October 202620 changes

Apps 4 · Sandboxes 8 · Billing 1 · Platform 2 · SDKs and CLI 3 · CI/CD 2

7 min read

NewerOlderFollow by RSS

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.

Other days.

Cut your cloud billby 75%.

No card to start. Billed by the second after.

Start free, no card