Render API for Apps
The web service endpoints of Render's REST API are served under /compat/render/v1, so Render API clients and the render CLI manage Apps by changing only their host (RENDER_HOST) and API key (Authorization: Bearer <key>). Supported: create an image-backed web service (POST /services, type web_service, runtime image), list, get, update its name, image, plan and health check path, scale (POST /services/{serviceId}/scale) and delete. Lists return [{"cursor", "service"}] and are paginated with cursor and limit (20 by default, at most 100), and can be filtered by name. The plans starter (the default), standard, pro, pro_plus, pro_max and pro_ultra create an App with 1, 1, 2, 4, 4 or 8 vCPUs and 0.5, 2, 4, 8, 16 or 32 GiB of memory, billed by measured use; each copy serves on port 10000, Render's default PORT. Errors return Render's status codes and {"id", "message"} body. A field or operation Apps does not support yet, such as repo or deploys, returns 400 or 404.
Desktops: E2B Desktop API
Desktops now accept E2B's sandbox REST API with its desktop template at /compat/e2b-desktop: set E2B_API_URL to https://<your API host>/compat/e2b-desktop and E2B_API_KEY to a Runtime API key, and E2B Desktop's SDKs (@e2b/desktop, e2b_desktop) can get, list (paginated by nextToken), connect to, extend the timeout of, pause and kill Runtime desktops. Creating a desktop from the desktop template with timeout and metadata is supported over the REST API; a timeout under 60 seconds returns 400. The SDKs' screen, mouse, keyboard, screenshot and stream methods, and their Sandbox.create(), which starts the screen through commands inside the sandbox, are not yet available. Desktops also gain spec.endsAt (a later time extends the timeout), and Browsers and Desktops gain status.endsAt.
Launch checks on /status.json
GET https://withruntime.com/status.json now returns launch_checks, one entry per product that launches with the next platform release (Browsers, Desktops, Notebooks, Dev environments, Actions runners, Cron, Apps, Functions, Containers, Load balancers, Firewall, Uptime checks, KV, Queues and Sites). Each hour, a test account creates, uses, reads back and deletes one resource of each product through the public API and confirms that its usage was billed. Three more entries run the same steps through a competitor's own SDK against Runtime's compatible API: browsers_browserbase (Browserbase's Node.js SDK), kv_cloudflare (Cloudflare's SDK) and functions_lambda (the AWS SDK for JavaScript's Lambda client). Each entry returns state (passed, failed or not_served), checked_at, total_ms, and steps_ms with the time of each step; a failed entry also returns failed_step and error.
Upstash QStash schedules API for Cron
QStash's schedules endpoints are served under /compat/qstash, so the @upstash/qstash client manages Cron jobs by changing only its base URL and token. Supported: create (POST /v2/schedules/{destination} with Upstash-Cron, Upstash-Method and the request body), get, list, pause, resume and delete. Each schedule is a job that sends the request to the destination on the cron schedule in UTC, with up to 3 retries, and is billed by measured use. A header not supported yet, such as Upstash-Retries or Upstash-Forward-*, returns 400 with its name. Errors return QStash's status and {"error"} body.
Balancer targets receive requests only after their first health check passes
When a balancer has spec.health, each target starts out of rotation: a new target, or every target on a host whose router has just restarted, receives no requests until its first health check passes, which happens within about 100 ms. One passing check is enough, whatever healthyThreshold is. While no target has passed yet, a request waits for the first check result instead of going to every target. If no target passes, requests go to all targets, as before. A target whose first check fails is reported unhealthy immediately.
Start action for Dev environments
POST /v2/dev-environments/{id}:start starts an environment immediately: a paused environment is woken, and a stopped one starts again from its disk, even when spec.state is already running. If spec.state holds another state, it is set to running. The response is the environment. Returns 409 (environment_stopping) while a stop is in progress, and 409 (environment_not_resumable) when the environment's disk was not kept. Every SDK has a start method. GitHub Codespaces' start (POST /user/codespaces/{codespace_name}/start under /compat/github) uses it, so it also starts a codespace that was shut down for being idle.
Cloud Run: gcloud run revisions list --service
In the Google Cloud Run Admin API at /compat/google-cloud-run, v1's namespaces.revisions.list now returns a service's revisions when labelSelector is serving.knative.dev/service=<name>, as gcloud run revisions list --service <name> sends it. Each revision is a version of the Container, as a Knative Revision, and only revisions of the service in the request's project and location are returned. A request without that selector, such as gcloud run revisions list with no --service, or with any other selector, returns 400. The v1 namespaces.revisions.list and namespaces.services.list methods also accept limit and continue: with either, the response is one page, and the next page's token is in metadata.continue. Without them, the response holds every item. A repeated labelSelector, limit or continue returns 400.
Containers: versions, and Cloud Run revisions
GET /v2/containers/{id}/versions returns a container's versions, newest first and paginated with limit (1 to 100, default 20) and cursor. GET /v2/container-versions/{id} returns one version by its ID, which is the container's ID, a dot, and the version's number (ctr_....3). Both accept the container's slug in place of its ID and require the key's containers:get permission. Each version returns its number, state (building, warming, ready, live, failed or superseded), image, imageDigest, failure, the container generation that made it, and the container's labels. The SDKs read them with containers.versions(id) and containers.version(id). In the Google Cloud Run Admin API at /compat/google-cloud-run, services.revisions.list (paginated with pageSize and pageToken) and services.revisions.get now return these versions as revisions named <service>-<version>, and v1's namespaces.revisions.get (gcloud run revisions describe) returns one as a Knative Revision. A revision of another service, location or project returns 404. Deleting a revision is not yet available, and v1's revisions list returns 404.
Sandboxes: a fork waits for room, as a create does
When no server has room for a copy, fork now retries with the same idempotency key for up to two minutes, as create, wake and restart do, in every SDK and in withruntime sandboxes fork. A fork refused for room pauses nothing and charges nothing. Set the wait as for a create (waitForCapacityMs in JavaScript, wait_for_capacity in Python and Ruby, WaitForCapacity in Go, waitForCapacity in Java); 0 fails immediately, and the CLI's --no-wait fails immediately. A fork of one copy now needs only the room a create of the same size needs; before, it needed four times its memory free on one server. A fork of many copies is still held to a quarter of each server's free memory past its first copy there, and is refused with details.fits when fewer copies fit. A fork that has already failed returns retryable: false, because its idempotency key returns the same error.
Containers: Cloud Run revisions are named, and traffic can be pinned to one
In the Google Cloud Run Admin API at /compat/google-cloud-run, each version of a Container is a revision named <service>-<version>, such as hello-3. In v2, a service now returns latestCreatedRevision (the newest version), latestReadyRevision (the version serving requests) and trafficStatuses. In v1, it returns status.latestCreatedRevisionName, status.latestReadyRevisionName and status.traffic[].revisionName. Sending 100% of traffic to one revision sets the Container's spec.version, which rolls it back to that version: in v2, traffic with type: TRAFFIC_TARGET_ALLOCATION_TYPE_REVISION and revision; in v1, spec.traffic with revisionName, as gcloud run services update-traffic --to-revisions hello-2=100 sends. Traffic to the latest revision (TRAFFIC_TARGET_ALLOCATION_TYPE_LATEST, or latestRevision: true) removes the pin. A revision of another service, a revision without a version number, or a revision named in a create returns 400. A traffic split between revisions returns 400, and revisions.list, revisions.get and revisions.delete are not yet available.
Better Stack TCP monitors keep their type
In the Better Stack compatibility API, a PATCH that changes a TCP monitor's monitor_type to status, keyword or expected_status_code now returns 400; previously it changed only the reported type while the check kept probing TCP. Delete the monitor and create a new one to change its type.
Better Stack TCP monitors
The Better Stack compatibility API at /compat/betterstack now accepts monitor_type: "tcp" with url (the host) and port, and creates an Uptime check on tcp://<host>:<port>; the monitor returns its host and port as Better Stack does. A TCP monitor without port returns 400. A TCP monitor's host and port, and a change to or from tcp, can't be updated, because an Uptime check's URL is fixed: such a request returns 400 (a port must be sent with its url); delete the monitor and create a new one.
Better Stack expected-status-code monitors
The Better Stack compatibility API at /compat/betterstack now accepts monitor_type: "expected_status_code" with expected_status_codes (a list of HTTP status codes); the Uptime check passes only those codes, and the monitor returns them as numbers. A request with that type and no codes returns 400. On other monitor types the codes are ignored, as on Better Stack, and changing a monitor to another type restores the default passing statuses (200 to 399).
Browserbase sessions accept keepAlive
POST /compat/browserbase/v1/sessions accepts keepAlive: true (previously 400). On Browsers, every session runs until its timeout (default 3600 seconds) or until you release it with REQUEST_RELEASE, whether or not a client is connected. A session created without keepAlive also keeps running after its client disconnects. To stop billing for it, release it or set timeout.
Containers: a slug addresses a container, and Cloud Run services keep the name requested
Containers accept an optional spec.slug: 1 to 63 lowercase letters, digits and hyphens, starting with a letter and not ending with a hyphen, unique within the project and set at create only. A create that repeats a slug in use returns 409 conflict, and the slug is released when the container is deleted. GET, PATCH and DELETE /v2/containers/{id} accept the slug in place of the ID; other kinds whose name is unique within the project, such as queues, accept that name the same way. A request by name requires the key's get permission on the kind. In the Google Cloud Run Admin API v2 at /compat/google-cloud-run, services.create now stores serviceId as the container's slug: the service's name is projects/{project}/locations/{location}/services/{serviceId}, and services.get, services.patch and services.delete accept that name. A second create with the same serviceId in the project returns 409 instead of returning the first service; a service created without serviceId is named by its container ID, as before. A slug is unique within a project, not within each location. A service's description now returns 400 instead of being stored as the container's name.
Browserbase session list rejects an unknown status
GET /compat/browserbase/v1/sessions returns 400 when status is not one of RUNNING, ERROR, TIMED_OUT, COMPLETED or PENDING (the values are case-sensitive), as Browserbase does. Previously it returned an empty list.
Console: the Sandboxes, Browsers and Desktops lists show every sandbox, wherever it runs
For many accounts the lists showed only sandboxes made before the account moved to Runtime's new servers, and none made since. The lists now include them for every account. A sandbox that moved while paused shows its current state; before, it showed paused, and a woken one was missing from the Running tab. "Stop all long-running" reads the same list.