LoginGet startedDashboard
Compare · Sandboxes

Sandal vs Cloudflare Sandboxes

Cloudflare Sandboxes expose container execution to Workers applications, with sessions, sleep behaviour and Durable Object coordination close at hand. Sandal draws a harder boundary, a microVM with its own kernel per machine, and is not tied to one application platform.

Start buildingSee the migration
Reviewed August 2026 · 3 sources
Isolation
ContainerCloudflareOwn kernelSandal
Paused sandbox
SleepCloudflare$0Sandal
Fork a running box
, CloudflareYesSandal
Surfaces on one SDK
LinuxCloudflareLinux · CI · mobileSandal
The honest split

Two good answers. Here is which one is yours.

Pick Cloudflare Sandboxes if
  • Your application already lives in Workers and wants sandbox calls next to Durable Object state.
  • You are standardised on Cloudflare deployment, bindings, observability and security controls.
  • Container isolation and the Sandbox SDK lifecycle fit the workload and its limits.
Pick Sandal if
  • You need the same API to also give the agent a CI runner, a desktop, or an iOS simulator.
  • Agents idle between turns and you refuse to pay wall-clock for a machine that is thinking.
  • Untrusted code needs its own kernel, default-deny egress and a key that dies with the machine.

Many teams run both. runs-on is per job and a sandbox is per task; nothing here is all or nothing.

Side by side

What each one actually ships.

Documented capability as of August 2026. Where the honest answer is a qualifier rather than yes or no, the qualifier is printed. Scroll sideways on a small screen.

Cloudflare Sandboxes compared with Sandal, August 2026
AreaCloudflare SandboxesSandalWhy it matters
Runtime
StateSessions and snapshot restore, with configurable sleep behaviour.Pause to $0 with memory intact, snapshots, and copy-on-write forks.Resuming is not the same as restoring.
Isolation
RuntimeCloudflare containers exposed through the Sandbox SDK and coordinated from Workers.KVM-backed Firecracker microVM with a dedicated kernel and filesystem.Untrusted code next to a shared kernel is the escape route you patch forever.
Pricing
BillingCloudflare container pricing while the sandbox is awake.Per second while the machine runs; paused costs nothing.Compare on your own workload; the units differ.
Surfaces
Platform scopeTightly integrated with Workers and Cloudflare application infrastructure.Linux, Windows and macOS machines, CI runners, iOS and Android simulators, Xcode builds.Agents eventually need a machine Workers does not sell.
Developer experience
Control planeWorkers bindings, Durable Objects, Cloudflare observability.A standalone SDK, CLI, REST API and MCP server that runs from anywhere.The glue is Cloudflare-specific and has to be replaced at the application boundary.
SDKsTypeScript, from a Worker.TypeScript and Python, CLI, REST, MCP.Python agent stacks need a client too.
Sources · reviewed August 2026

Capabilities change and rates change. If something here is out of date, tell us and we will fix it the same week.

Price

Same shape. Two meters.

Cloudflare prices containers by vCPU, memory and disk seconds through Workers; there is no single published rate for this shape, so we do not print one. Sandal publishes $0.036 per hour for 4 vCPU / 8 GiB, August 2026.

Cloudflare Sandboxes4 vCPU / 8 GiB
Cloudflare container rates, see the Workers pricing page
Sandal4 vCPU / 8 GiB · paused = $0
0.036$ / hour
Price your own fleetThe full rate card
How to compare

Normalise both vendors on the same unit before you compare: one sandbox, one hour, the same size. Sandal meters per second and a paused machine costs nothing, so a bill for bursty work is the sum of the seconds it actually ran.

Open the rate card →
Migration

Same shape, native SDK.

The lifecycle maps one to one, create, exec, files, stop, so the port is a small rewrite, not a re-architecture. Keep the vendor-specific glue on your side of the boundary.

worker.ts−1 +1same shape, native SDK
-import { getSandbox } from "@cloudflare/sandbox";
+import { Sandal } from "@sandal/sdk";
+const sandal = new Sandal({ apiKey: env.SANDAL_API_KEY });
-const sbx = getSandbox(env.Sandbox, "agent-7c31");
-await sbx.exec("pnpm test");
+const sbx = await sandal.sandboxes.create({ template: "node-22" });
+await sbx.exec("pnpm test");
+await sbx.pause(); // $0 until the next turn
  1. 01≈ 2 min

    Install the SDK

    npm install @sandal/sdk and add one API key to the Worker’s environment.

  2. 02≈ 30 min

    Port the lifecycle

    exec, files and previews map directly. Durable Object coordination stays in the Worker; the machine moves.

  3. 03≈ 1 afternoon

    Run both, side by side

    Same job on each for a day; compare start time, isolation and the bill.

Where Cloudflare Sandboxes is ahead

What we would rather you read here than find later.

A comparison page where the vendor wins every row is a brochure. These are real, and we would rather you land on the right tool than land on us and leave in a month.

  • 01

    Next to your Workers.

    If the application is already a Worker with Durable Object state, keeping the sandbox call on the same platform is less glue, one bill, and one set of security controls.

Before you switch

Questions teams ask before moving off Cloudflare Sandboxes.

A container, exposed through the Sandbox SDK and coordinated from Workers. Sandal sandboxes are Firecracker microVMs with a dedicated kernel per machine.

More comparisons

The rest of the field in sandboxes.

All comparisons and the full matrix →
Get started

Run the same job twice.

Point one workload at Sandal and one at Cloudflare Sandboxes. The numbers on this page are ours; the ones that matter are yours.

Start buildingRead the docs
npm i @sandal/sdk