Skip to content

Changelog

New updates and improvements at Cloudflare.

Sandbox SDK 1.0: control every sandbox from your own Durable Object

Sandbox SDK 1.0 is available. Your own Durable Object class now controls each sandbox container directly, through the Durable Object container API on this.ctx.container.

With 1.0, your class can:

  • Choose the image and instance size each time it starts a sandbox. One class can run sandboxes on different images, and a deploy does not restart sandboxes that are running.
  • Save the files of a sandbox as a snapshot, in public beta, and start the same sandbox or a new one from it.
  • Decide when each sandbox stops, for example when a task finishes, when its user goes idle, or after it saves a snapshot.
  • Run commands with streamed input and output, send them signals, and open terminals.
  • Serve previews from ports in the sandbox, with your own hostnames and authentication.
  • Handle outbound requests for each hostname in Worker code, so credentials and bindings stay in your Worker.
  • Expose only the methods that you want callers to use.
  • Run an agent in the same Durable Object, and give the model a tool that runs commands in the sandbox.
src/index.jsjs
import { Files } from "@cloudflare/sandbox";
import { DurableObject } from "cloudflare:workers";

export class MySandbox extends DurableObject {
	container;
	files;

	constructor(ctx, env) {
		super(ctx, env);
		if (!ctx.container) {
			throw new Error("No container is configured");
		}
		this.container = ctx.container;
		this.files = new Files(ctx.container);
	}

	async run(script) {
		if (!this.container.running) {
			// Your code chooses the image, size, and network access.
			this.container.start({
				image: this.container.images.sandbox,
				instance: "lite",
				enableInternet: false,
			});
		}

		await this.files.writeFile("/tmp/task.sh", script);
		const proc = await this.container.exec(["sh", "/tmp/task.sh"]);
		return proc.output();
	}
}
src/index.tsts
import { Files } from "@cloudflare/sandbox";
import { DurableObject } from "cloudflare:workers";

export class MySandbox extends DurableObject<Env> {
	private readonly container: Container;
	private readonly files: Files;

	constructor(ctx: DurableObjectState, env: Env) {
		super(ctx, env);
		if (!ctx.container) {
			throw new Error("No container is configured");
		}
		this.container = ctx.container;
		this.files = new Files(ctx.container);
	}

	async run(script: string) {
		if (!this.container.running) {
			// Your code chooses the image, size, and network access.
			this.container.start({
				image: this.container.images.sandbox,
				instance: "lite",
				enableInternet: false,
			});
		}

		await this.files.writeFile("/tmp/task.sh", script);
		const proc = await this.container.exec(["sh", "/tmp/task.sh"]);
		return proc.output();
	}
}

Your class uses the container API directly, with the durable_object scheduling policy and container snapshots, both in public beta. @cloudflare/sandbox adds classes for work that the API does not include:

  • Files streams files in and out of the running sandbox.
  • S3Mount mounts an S3-compatible bucket, such as R2. Your Worker signs each storage request, so the credentials stay out of the sandbox.
  • DirectoryBackup saves a directory to R2 and restores it into any sandbox, including one on a newer image.

If you use Sandbox SDK 0.x

Your 0.x applications keep running, and @cloudflare/sandbox 0.x stays on npm. Sandbox SDK 0.x receives bug and security fixes until 2026-12-31, and its documentation stays at Sandbox SDK 0.x.

When you are ready, Migrate from Sandbox SDK 0.x shows the 1.0 code for each 0.x feature, including preview URLs, tunnels, background processes, terminals, backups, and the code interpreter. The guide keeps the preview URLs and named tunnels that your 0.x application created working. You can move every sandbox in one deploy, or run a 1.0 class next to your 0.x class and move sandboxes one at a time. The deploy that moves an existing class to the new policy is one-way, so the guide shows how to rehearse it first.

The Sandboxes documentation also covers Dynamic Workers, for untrusted code in JavaScript, Python, or WebAssembly.

Run Cursor Cloud Agents on Cloudflare via self-hosted machines

Cursor self-hosted machines ↗︎ let you run Cursor Cloud Agents on Cloudflare. Each assigned session runs in its own isolated environment backed by Cloudflare Containers.

Cursor Cloud Agents environment selector showing the cloudflare-pool self-hosted machine pool

Cursor hosts the agent loop, inference, and planning. Cloudflare runs commands, file edits, repository operations, and other tools inside infrastructure that you control. The open-source Cursor Cloudflare Workers template ↗︎ deploys the Worker, Durable Object namespace, container application, R2 bucket binding, and cron trigger used by the integration.

To get started, refer to Run Cursor Cloud Agents on Cloudflare via self-hosted machines.

Run Devin on Cloudflare using Devin Outposts

Devin Outposts ↗︎ lets you run Devin agents on Cloudflare. Each Devin session runs in its own isolated sandbox backed by Cloudflare Containers, so agents can execute code and use development tooling in an isolated environment.

Use Devin Outposts when you want Devin sessions to run on Cloudflare managed infrastructure, with each session isolated from the others.

Devin interface showing Cloudflare selected as an Outposts virtual environment

To get started, refer to Run Devin on Cloudflare using Devin Outposts.

Deprecating Sandbox SDK features

Today we are announcing the deprecation of several features from the Sandbox SDK. The SDK has grown and matured substantially since it first launched. As agent workflows have developed, we have shipped many new features and experiments so developers can easily integrate secure, isolated code execution into their workflows.

We want the SDK to continue providing a stable foundation for agentic workflows while we iterate quickly on the codebase. These deprecated features have either been superseded by newer capabilities or seen low adoption. Do not build new work on them. Migrate using the 2026 deprecation migration guide, or move to the Sandbox SDK 1.0 preview when you can.

HTTP and WebSocket transports

In April 2026, we released the new RPC transport and deprecated the WebSocket transport. This setting governs how the sandbox container talks to the Workers ecosystem. The RPC transport removes the limitations of both the HTTP and WebSocket transports. As of this announcement, RPC is the recommended default. HTTP and WebSocket transports are deprecated and will not ship in future Sandbox SDK majors.

To migrate, update the SANDBOX_TRANSPORT variable to rpc or set the transport option when calling getSandbox(). For more information, refer to the transport configuration documentation.

Desktop

The desktop feature ran a full Linux desktop inside the sandbox (display server, desktop environment, and VNC/noVNC) so agents and apps could drive a GUI with screenshots, mouse, and keyboard — the same computer-use shape other sandbox products expose for UI automation. Adoption stayed low, and we removed it in 0.10.2. If you need that capability again, you can build it on top of the sandbox with extensions rather than a built-in sandbox.desktop API.

Expose ports

We recently released support for Cloudflare Tunnel in the Sandbox SDK. This provides a robust API for exposing services running in your sandbox to the public internet. It fixes issues many were facing with local development and deployment to workers.dev domains. To migrate from exposePort() to tunnels, refer to the tunnels API documentation and the expose services guide.

Default sessions

By default, the exec() method in the Sandbox SDK maintains a default session across all calls, so a cd in one call is honored in the next. This convenience helped developers writing exec statements by hand, but confused agents and caused hard-to-trace bugs. As of 0.10.3, we have introduced the enableDefaultSession flag on the getSandbox() interface to turn this off. Default sessions as a concept — and the flag — will be removed in an upcoming release.

We recommend setting enableDefaultSession: false today and using the sandbox.createSession() API when you need the previous behavior.

Other changes

We are also consolidating all APIs that buffer data to support streaming by default. This includes readFile, writeFile, and exec. The stream equivalents will be removed.

We are exploring moving non-core features like the code interpreter, terminal, and git APIs into helpers. These features will retain their existing APIs, so migration should be simple.

Next steps

If you use any of these features on the current stable package, refer to the 2026 deprecation migration guide. Coding agents can use the sandbox-stable skill for stable-package work and that guide for cleanup (Agent setup · Cloudflare Skills ↗︎).

If you are moving to Sandbox SDK 1.0 (@next), use the 1.0 preview and Migrate guides instead — or the sandbox-migrate-to-next skill after installing Cloudflare Skills. New projects should prefer sandbox-next on @next.

For any questions, ask in the Cloudflare Developers Discord ↗︎.