WebAssembly sandboxes against V8 isolates: the two serious edge platforms compared on runtime, limits and money.
Winner depends on your workload.
Winner depends on: your language and isolation requirements, how much of the surrounding platform (storage, queues, databases) you want from the same vendor, and whether your unit economics favor CPU-time or request-based billing.
Side by side
| Fastly Compute | Cloudflare Workers | |
|---|---|---|
| Runtime | WebAssembly (WASI), fresh sandbox per request | V8 isolates, long-lived, many requests per isolate |
| Startup | ~35 microseconds, no cold starts | Effectively no cold start for warm isolates |
| Languages | Rust, JavaScript, Go — anything compiling to Wasm | JS/TS first-class; Wasm supported; Python (beta lineage) |
| Key limits | Per-request isolation; platform limits per plan | 128 MB/isolate; CPU 30 s default → 5 min (paid); 10 ms free tier |
| Billing basis | Requests (duration metric retired for new customers, Mar 2026) | $5/month: 10M requests + 30M CPU-ms; overage $0.30/M req, $0.02/M CPU-ms |
| Ecosystem | KV store, Fanout, dynamic backends, programmable cache | KV, R2, D1, Durable Objects, Queues, Workers AI |
Two answers to multi-tenancy
Both platforms exist because containers are too slow to start at the edge, and both answer the same question — how do you run untrusted code from thousands of tenants on shared machines — differently. Cloudflare runs JavaScript in V8 isolates: lightweight contexts inside a shared process, long-lived, each serving many requests. Fastly compiles your code to WebAssembly and instantiates a fresh memory-safe sandbox for every single request, with a startup time it measures at roughly 35 microseconds. The isolate model amortizes; the sandbox model isolates. That single design choice explains most of the downstream differences.
Runtime and developer experience
Workers is the easier on-ramp: write JavaScript or TypeScript, deploy with Wrangler in seconds, and lean on an ecosystem — KV, R2 zero-egress storage, D1 SQLite, Durable Objects for coordination, Queues — that has grown into a genuine application platform. Compute asks slightly more: your Rust, JavaScript or Go compiles to Wasm, and the reward is per-request isolation (no shared-state footguns between requests, a materially smaller side-channel surface) plus first-class access to Fastly’s delivery machinery — the programmable cache, dynamic backends chosen at runtime, and Fanout for WebSocket-style push at the edge.
Limits and pricing, with workings
Workers publishes crisp numbers: the free tier allows 100,000 requests/day at 10 ms CPU each; the $5/month paid plan includes 10 million requests and 30 million CPU-milliseconds, with overage at $0.30 per million requests and $0.02 per million CPU-ms, CPU capped at 30 seconds by default and raisable to five minutes, memory at 128 MB per isolate. Crucially, only CPU time bills — waiting on fetch() is free. Worked example: 50 million requests/month averaging 5 ms CPU = $5 + (40M × $0.30/M) + (220M CPU-ms × $0.02/M) ≈ $21.40.
Fastly prices Compute by requests within its broader platform pricing — and notably, for customers purchasing after 17 March 2026, the separate compute-duration meter was retired, simplifying the model to request-based charges. Fastly runs no free production tier (trial credits aside) and expects platform-level minimums, so Compute is rarely bought alone: it makes sense as the programmable layer of a Fastly delivery estate. Figures checked against provider documentation, July 2026.
Where each one wins
Choose Workers when the platform is the point: you want compute, storage, queues and a database from one vendor with near-zero adoption cost, or your team is JavaScript-native and values iteration speed above all. Choose Compute when the delivery layer is the point: you are already on Fastly for the reasons covered in Fastly vs Akamai for media, you want request-level isolation for compliance or multi-tenant safety, or you write Rust and want the fastest deterministic startup in the industry. Teams comparing against the hyperscaler equivalents should read CloudFront Functions vs Lambda@Edge alongside this piece — the AWS pair splits the problem differently again.
The honest verdict
These are the two most serious edge runtimes shipping today, and neither is a mistake. Workers wins on ecosystem breadth and cost transparency; Compute wins on isolation rigor and integration with a delivery network that engineering teams already prize. The deciding vote is usually cast by everything around the runtime — storage, delivery contract, team language — not by the runtime itself.
Choosing an edge platform alongside a delivery renewal? The assessment models both stacks against your workload and contract calendar.