Benchmarking Cloudflare Containers vs AWS MicroVMs | alchemy
Skip to content
Benchmarking Cloudflare Containers vs AWS MicroVMs
Jul 1, 2026
We benchmarked cold starts for AWS Lambda MicroVMs and<br>Cloudflare Containers: boot a fresh instance, wait until it<br>answers a real request, record the time, tear it down, repeat.<br>700 boots across 16 variants.
The result, if latency is what matters to you: use AWS<br>MicroVMs for your sandboxes even if everything else you run is<br>on Cloudflare . In this benchmark, booting a MicroVM from a<br>Cloudflare Worker — cross-cloud, over the public AWS API — was<br>faster and far more predictable than Cloudflare’s own<br>containers on Cloudflare’s own platform. And with Alchemy’s<br>bindings, wiring a MicroVM into a Worker or Durable Object is a<br>few lines of code — we’ll show it below.
We ran opencode as one of the workloads<br>because it’s a popular coding agent that runs as a local<br>process, weighs about 100 MB, and has real startup latency —<br>exactly the kind of thing you’d host in a per-user sandbox. A<br>boot counts as ready when the server answers its health check<br>and creates a real session. Here’s how the distributions<br>compare, opencode and hello world on both platforms:
And the same data as individual boots — this view is what the<br>density curves smooth over, the container outliers at 20, 40,<br>nearly 60 seconds:
p50p95maxCloudflare Container — opencode (via Worker)10.5s15.6s58.6sAWS MicroVM — opencode (via Lambda)3.4s4.1s4.5sAWS MicroVM — opencode (via Worker)3.6s4.0s4.2sCloudflare Container — hello world (via Worker)1.7s23.9s47.3sAWS MicroVM — hello world (via Lambda)2.7s3.2s3.7sAWS MicroVM — hello world (via Worker)3.1s3.8s5.4s<br>What’s remarkable in that table is AWS’s consistency. Look at<br>the two workloads on MicroVMs: hello world is 2.7 seconds at<br>the median, opencode is 3.4. A 100 MB coding agent with real<br>startup work costs 0.7 seconds more than a 15-line server —<br>because on AWS, everything goes through the same path. When<br>AWS builds a MicroVM image, it doesn’t just build the<br>Dockerfile — it runs the entrypoint, waits for the<br>application to initialize, and takes a Firecracker snapshot of<br>the running memory and disk<br>(launch post).<br>Every RunMicrovm resumes from that snapshot, so the workload’s<br>startup is paid once, at build time. The flip side is that a<br>lighter image doesn’t boot faster — it goes through the same<br>snapshot restore. Boot time on AWS is a property of the<br>platform, not the workload: 2 to 4.5 seconds, whatever’s inside.
Cloudflare is the opposite: boot time is a property of the<br>workload, plus a tail you can’t control. For small, light<br>containers that edge is real — the hello-world container is<br>ready in 1.7 seconds at the median, ahead of anything on AWS.<br>But a container cold start boots the image from scratch and<br>runs the entrypoint, so every single container pays opencode’s<br>full startup: the fastest opencode container in the run took<br>4.4 seconds and two-thirds took over 10. And the long tail has<br>nothing to do with the workload — the hello-world container<br>shows the same outliers in the scatter plot as the opencode<br>one, with about one boot in ten over 10 seconds and the worst<br>near 50. Yes, a Cloudflare container can be faster; it can also<br>be 30–40 seconds slower, and you can’t predict which you’ll get.
For anything a person actually watches, AWS’s consistency is<br>the better trade. You never want a user staring at a spinner<br>for 10–60 seconds when they could wait 2–4.5, every time. A<br>predictable 3 seconds is something you can design an experience<br>around; an unpredictable 1-to-60 is not. Not one of the 49<br>successful opencode MicroVM boots exceeded 4.5 seconds.
The “via Worker” MicroVM rows are the proof of the claim at the<br>top: those MicroVMs were booted from a Cloudflare Worker ,<br>and they beat Cloudflare’s own containers whenever the workload<br>is heavy enough that startup matters. Crossing clouds costs<br>nothing measurable — how that wiring works is covered below.
The entire opencode image is this:
FROM public.ecr.aws/lambda/microvms:al2023-minimal
RUN curl -fsSL https://opencode.ai/install | bash
WORKDIR /workspace
ENTRYPOINT ["opencode", "serve", "--hostname", "0.0.0.0", "--port", "8080"]
The snapshot behavior isn’t configured — it’s what building a<br>MicroVM image means.
The same shape without the workload<br>Section titled “The same shape without the workload”
Strip the workload away and the platforms keep the same<br>characters. These are the hello-world variants — a 15-line<br>Bun.serve on both platforms:
Cloudflare Containers are fast at the median — around 2<br>seconds — but the samples scatter out to 20, 40, nearly 50<br>seconds. AWS MicroVMs cluster between 2 and 4 seconds. The<br>distribution view makes the trade explicit:
The container curves race ahead early and then go flat. Flat is<br>the problem: 73–90% of boots are done by 3 seconds, and then the<br>curve stalls — the remaining 10–27% of your users are waiting<br>10, 20, 40+ seconds. Every point in that flat stretch is a<br>person...