Cloudflare Sandbox SDK 1.0 hands each sandbox to a Durable Object class you write; 0.x fixes end December 31

The quick read

What actually changed

The two primitives underneath

What a snapshot leaves behind

Where the control model stops

• The scheduling policy is fixed at creation. Moving a container application onto durable_object means creating a new application and replacing every running instance, because the policy cannot change afterwards. 5
• max_instances disappears. The durable_object policy does not support it. Running instances count against the account limits instead: 6 TiB of concurrent memory, 1,500 vCPU, and 30 TB of disk. 510
• Image updates become your code's job. Durable-Object-managed instances take no part in application-wide image rollouts, and a running instance keeps the image it started with until your code stops it and starts another. During a gradual deployment, ctx.container.images reflects the Worker version running the Durable Object, so two Durable Objects can start from different images until the deployment finishes. 5
• A running instance refuses a second start(). The call throws while an instance runs, and a deploy leaves that instance running with the image, entrypoint, and environment variables it started with. 712
• exec() runs inside an already-running container. It starts another process and waits for a container that is still starting, while a stopped container stays stopped. Output collected by output() sits in the Durable Object's memory and counts against the Worker memory limit, so a large output wants the streams read as they arrive. 12
• Containers speak HTTP. Every request arrives through the Worker, so an end user cannot open a raw TCP or UDP connection to an instance. Each instance runs in a Firecracker microVM with its own kernel and network, images are built for linux/amd64, and a cold start from a fully stopped state commonly takes one to three seconds. 13
• The plan is Workers Paid. Sandboxes run on the Workers Paid plan, with memory, CPU, and disk billed per 10 ms while an instance runs. The $5/month plan includes 25 GiB-hours of memory, 375 vCPU-minutes, and 200 GB-hours of disk each month. 89

Migrating off Sandbox SDK 0.x

1. Pin what you run today. Stay on @cloudflare/sandbox 0.12.10 with the matching docker.io/cloudflare/sandbox:0.12.10 image while you plan, because the migration pages compare 1.0 against 0.12. 2
2. Find every 0.x call. Search your source for getSandbox, createSession, exposePort, mountBucket, createBackup, and the rest; Cloudflare prints the full list, and each name leads to one migration page. 2
3. Replace the Sandbox class with a Durable Object class that starts its own container under the durable_object policy. Every application needs this one change. 2
4. Work through the feature pages for command calls, file calls, background processes, preview URLs, tunnels, terminals, outbound rules, bucket mounts, backups, and the code interpreter. 2
5. Choose the cut-over shape. Move every sandbox in one deploy, or run a 1.0 class beside the 0.x class and move sandboxes one at a time. Rehearse on a staging Worker either way, because the deploy that moves an existing class to the new policy is one-way. 2
6. Move the workspace into snapshots. Where 0.x relied on a long-running instance to keep a workspace, 1.0 asks you to save a snapshot before the instance stops and restore it on the next start(). A live preview server is one thing a snapshot leaves behind, so your class starts it again. 27

Verdict: adopt for agent sandboxes, move 0.x this quarter