# Cloudflare Sandbox or Lambda MicroVMs?

> My product runs code nobody reviewed, written by an LLM or a customer. Where does it run safely, and which fits which business? Cloudflare Sandbox by default: a ready-made toolkit for running code, billed on active CPU, about a quarter of the price for short bursts. Lambda MicroVMs as soon as the code must run in Australia, reach a private VPC, use more than 4 vCPU, or keep its running processes through long sessions. Sandbox isn't in Pulumi yet: a small custom provider (about 3–5 days) or wrangler wrapped in Pulumi closes the gap.

- A choice between tools from The Stack by Nicolas Dao (Cloudless Labs, Sydney): when to pick each, and when to run both
- Last reviewed: 30 October 2026, by Nicolas Dao
- Web page: https://cloudlesslabs.com/stack/guides/sandbox-or-microvms/. The whole stack in one file: https://cloudlesslabs.com/stack/brief.md
- Tools: [Cloudflare Sandbox](https://cloudlesslabs.com/stack/cloudflare-sandbox/index.md) (Use when it fits), [Lambda MicroVMs](https://cloudlesslabs.com/stack/aws-lambda-microvms/index.md) (Watching), [Cloudflare Workers](https://cloudlesslabs.com/stack/cloudflare-workers/index.md) (My default), [AWS Lambda](https://cloudlesslabs.com/stack/aws-lambda/index.md) (My default), [Pulumi](https://cloudlesslabs.com/stack/pulumi/index.md) (My default)

## When to pick which

Pick Cloudflare Sandbox when:

- Code runs in short bursts: a data-analysis chat running Python on a user's spreadsheet, a code interpreter in a SaaS feature.
- The product is on Workers, and neither Australian residency nor a private VPC is required.
- You want the toolkit ready: run commands and code, files, a terminal, preview URLs, backup and restore.

Pick Lambda MicroVMs when:

- The data must stay in Australia: MicroVMs run in Sydney, and Cloudflare can't pin a container there.
- The code reads private data in a VPC, such as the client's Postgres.
- Long sessions whose running processes must survive the user leaving: a coding agent's dev server, a build.
- More than 4 vCPU or 12 GiB, or a government client that needs the work inside its AWS account.

Pick Neither when:

- The code is yours and reviewed, even if an agent wrote it: a Lambda, a Worker or a Fargate task is enough.

Both, when:

- Not in one product without a reason: two runtimes to build and maintain. Across a portfolio, yes: Sandbox for the products on Workers, MicroVMs for the clients who need Australia or their VPC.
- One product can justify both when an enterprise tenant requires Australian residency: Sandbox for everyone else, MicroVMs for that tenant, if the tenant pays for the second runtime.

Questions that change the answer:

- Who wrote the code that will run? If it's your team, reviewed, you don't need a sandbox.
- Must the code or the data stay in Australia? Then it's Lambda MicroVMs.
- Does the code need private data in a VPC? Then it's Lambda MicroVMs.
- How long is a session, and must its running processes survive a pause? Seconds to minutes points to Sandbox, hours with a running dev server to MicroVMs.
- Must everything be provisioned with Pulumi today? MicroVMs are; Sandbox needs a small custom provider or a wrapped wrangler.

## Do you need a sandbox at all?

Only when your product runs code that nobody on your team reviewed: code an LLM writes at runtime, or code a customer uploads. That code must never run where your credentials live. A normal Lambda runs with its function's role and environment variables, and its `/tmp` survives into the next invocation; hardening it into a sandbox is a project in itself.

If the code is yours, written by Claude Code on a laptop and reviewed before it ships, you need neither of these. A Lambda, a Worker or a Fargate task does the job.

## The short version

| | Cloudflare Sandbox | Lambda MicroVMs |
|---|---|---|
| My verdict | Use when it fits: my default for this job | Watching |
| What you get | A toolkit, driven from a Worker through an SDK: run commands, Python and JavaScript, files, a terminal, preview URLs, backup and restore | A raw isolated server: your own app in a Firecracker VM, reached through an HTTPS endpoint (HTTP/2, gRPC, WebSocket). No exec SDK: you build the server inside |
| Isolation | A container per session | A Firecracker microVM per instance |
| State | Files, through backup and restore | Memory and disk: suspends when idle and resumes on the next request with its processes running, for up to 8 hours in all |
| Sizes | 1/16 vCPU and 256 MiB up to 4 vCPU, 12 GiB and 20 GB of disk | 1 vCPU and 2 GB up to 16 vCPU, 32 GB and 32 GB of disk |
| CPU architecture | amd64 | Arm64 |
| Billing | Active CPU, plus the memory and disk you provision while it runs | A baseline, every second it runs, busy or idle; suspended, only the snapshot |
| Network | Outbound through a Worker that adds credentials per destination, so the code never sees them | Public internet or your VPC, through a network connector |
| Where | Cloudflare's network; can't be pinned to Australia | Sydney, since August 2026 |
| Pulumi | Partly: the container attaches to a Worker in the Cloudflare provider; the image and the container application go through wrangler | Official, in `@pulumi/aws` |
| Scale | Per account: 1,500 vCPU, 6 TiB of memory and 30 TB of disk running at once | Quotas not published |

## Priced: two real cases

Rates: Sandbox $0.000020 per active vCPU-second, $0.0000025 per GiB-second of memory and $0.00000007 per GB-second of disk, plus Workers Paid at $5 a month. MicroVMs at AWS's US East Arm rates, $0.0000276944 per vCPU-second and $0.0000036667 per GB-second, so the 1 vCPU / 2 GB baseline is about $0.126 a running hour; snapshots $0.0038 per GB written and $0.00155 per GB read. Free allowances left out (under $1). Egress not included.

**A data-analysis chat: 50,000 sessions a month,** each open 5 minutes, 20 seconds of CPU on 1 vCPU.

| | Per session | Per month |
|---|---|---|
| Sandbox (1 vCPU, 3 GiB, 8 GB of disk) | CPU $0.0004 + memory $0.00225 + disk $0.00017 = $0.0028 | about $141, plus $5 |
| MicroVMs (1 vCPU, 2 GB, stopped at the end) | 300 seconds at the baseline: $0.0105 | about $525 |

Sandbox is about 3.7 times cheaper. Suspending the MicroVM between a user's questions doesn't help: one suspend and resume of a 3 GB snapshot costs about $0.016, more than the session's compute.

**A coding agent: 500 sessions a month at 2 vCPU and 8 GB,** each 3 hours: one hour of work with the CPU half busy, then two hours with the user away.

| | Per session | Per month |
|---|---|---|
| Sandbox, left running so its processes survive | CPU $0.072 + memory $0.216 + disk $0.012 = $0.30 | about $150 |
| Sandbox, stopped while the user is away (files restored, processes lost) | $0.15 | about $74 |
| MicroVMs, suspended while the user is away (memory and processes kept) | active hour about $0.31 + one suspend and resume of about 10 GB, $0.05 = $0.36 | about $180 |
| MicroVMs, left running | $0.56 | about $280 |

Here they're close: Sandbox is cheaper if losing the running processes is acceptable, and MicroVMs cost about 20% more to bring the user back to the same running dev server, in Sydney, inside the VPC. The MicroVM figures assume the resources above the baseline are billed only while used, as AWS describes them; the exact metering isn't published in detail.

## Which one, for which business

- **"Ask your data" in a SaaS product: Sandbox.** A user uploads a spreadsheet and asks which region's sales dropped; the model writes Python, runs it on the file and returns a chart. Seconds per run, thousands of users, idle in between: Sandbox's `runCode` and file handling are already there, and you pay only while the code is on the CPU.
- **An AI coding agent on a real repository: MicroVMs.** An internal agent that clones a client's repository, installs dependencies, runs the tests and starts a dev server for review, or an "AI builds your app" product. Sessions last hours and the user leaves for lunch: the VM suspends with `node_modules`, the dev server and its memory intact, and resumes as if nothing happened.
- **Customer-written rules in an enterprise platform: MicroVMs.** An IoT platform where each client writes its own alert rules or transforms on its sensor data, a learning platform grading the code students submit, a rules engine running customers' scripts. The code reads that tenant's data in the private Postgres, and the data stays in Australia: only MicroVMs do both.
- **Opening untrusted files: MicroVMs.** Scanning uploaded binaries or opening suspicious documents deserves a full VM's isolation, inside the AWS account with the rest of the security tooling.

## Cloudflare Sandbox in Pulumi

Pulumi and Terraform providers are wrappers around a vendor's web API, and Cloudflare documents a Containers API (container applications, their image and instance type, rollouts, and registry credentials). Wrangler uses the same API: it fetches a 15-minute registry login, pushes the image to `registry.cloudflare.com`, creates or updates the container application and starts a rollout. Nobody has wrapped it yet: Pulumi has no roadmap item, and a pull request adding a container resource to Cloudflare's Terraform provider was closed unmerged in March 2026.

| Option | Effort | What you get |
|---|---|---|
| A command resource running `wrangler deploy`, keyed on a hash of the source | Half a day to a day | It works, but Pulumi can't see what's deployed (no drift detection), and the machine running it needs Docker |
| A small TypeScript provider of our own (a Pulumi dynamic provider) for the application, plus `@pulumi/docker-build` for the image | About 3–5 days | Real Pulumi resources: create, update, delete and drift detection against the API, the image pinned by its digest, alongside the Cloudflare provider that attaches the container to the Worker |
| A full provider in Go | 1–2 weeks, plus maintenance | Only worth it to publish for others |

I'd build the second the first time a client project needs Sandbox, and drop it the day Cloudflare ships an official resource. Part of the rollout API wrangler calls isn't fully documented, so it's ours to maintain until then.

## What still forces Lambda MicroVMs

| A client needs | Cloudflare Sandbox | Lambda MicroVMs |
|---|---|---|
| The data to stay in Australia | Blocked. Containers offer only the `eu`, `us` and `fedramp` jurisdictions, and Oceania is "limited capacity" that can't be used on its own without dedicated access from Cloudflare's support | Sydney |
| Access to a private VPC | Only through the Worker's outbound handler, which carries HTTP. Cloudflare's private-network product (Workers VPC) is in beta and doesn't mention containers; a direct database connection from the container isn't confirmed | Native, through a network connector |
| More than 4 vCPU or 12 GiB | Blocked: 4 vCPU, 12 GiB and 20 GB of disk at most | Up to 16 vCPU and 32 GB |
| Government work under IRAP | Cloudflare's Australian assessment lists Workers, R2 and Durable Objects, not Containers (not confirmed) | Not confirmed either: new AWS services take time to join the assessed list. Check with the client |

Sources, checked on 30 October 2026: [Cloudflare Containers pricing](https://developers.cloudflare.com/containers/pricing/), [limits](https://developers.cloudflare.com/containers/platform-details/limits/), [placement and jurisdictions](https://developers.cloudflare.com/containers/platform-details/placement/), [the Containers API](https://developers.cloudflare.com/api/resources/containers/), [Workers VPC](https://developers.cloudflare.com/workers-vpc/), [the closed Terraform pull request](https://github.com/cloudflare/terraform-provider-cloudflare/pull/6854), [Pulumi dynamic providers](https://www.pulumi.com/docs/iac/concepts/resources/dynamic-providers/), [Lambda MicroVMs](https://aws.amazon.com/about-aws/whats-new/2026/06/aws-lambda-microvms), [MicroVMs in Sydney](https://aws.amazon.com/about-aws/whats-new/2026/08/lambda-microvms-5-additional-regions), [Lambda pricing](https://aws.amazon.com/lambda/pricing/).

## Related

- [AI that runs the code it writes](https://cloudlesslabs.com/stack/use-cases/ai-code/index.md): the use case this guide works through
- [Cloudflare Sandbox](https://cloudlesslabs.com/stack/cloudflare-sandbox/index.md): the full entry (verdict, pricing, gotchas)
- [Lambda MicroVMs](https://cloudlesslabs.com/stack/aws-lambda-microvms/index.md): the full entry (verdict, pricing, gotchas)
- [Cloudflare Workers](https://cloudlesslabs.com/stack/cloudflare-workers/index.md): the full entry (verdict, pricing, gotchas)
- [AWS Lambda](https://cloudlesslabs.com/stack/aws-lambda/index.md): the full entry (verdict, pricing, gotchas)
- [Pulumi](https://cloudlesslabs.com/stack/pulumi/index.md): the full entry (verdict, pricing, gotchas)
- [Where may the data go?](https://cloudlesslabs.com/concepts/data-residency/index.md): the concept behind it
- [Where should code nobody reviewed run?](https://cloudlesslabs.com/concepts/sandboxing/index.md): the concept behind it
- [Every decision guide, the choices between tools first](https://cloudlesslabs.com/stack/guides/index.md)
- [Map of every Markdown file on cloudlesslabs.com, with what each one answers](https://ask.cloudlesslabs.com)