Cloudflare Workers vs Fastly Compute: The Edge Runtime Decision

Cloudflare Workers and Fastly Compute sell the same promise: run your code in dozens of cities, a few milliseconds from the user, with no servers to babysit. They get there on opposite bets. Workers runs JavaScript in V8 isolates, the same engine inside Chrome. Fastly compiles your code to WebAssembly and spins up a fresh sandbox for every single request.

That one architectural fork decides almost everything downstream: which languages feel native, how tenants are isolated, how cold starts behave, and how large the surrounding ecosystem is. It is also the cleanest example of WebAssembly leaving the browser for production infrastructure. Fastly bet the whole platform on Wasm. Cloudflare treats it as an escape hatch. Understanding why is most of the decision.

The two contenders

Both are mature, production-real edge platforms with overlapping scope. The honest framing is that they solved the same density problem, many tenants per machine with sub-millisecond switching, using different isolation primitives.

Sources: Cloudflare security model and network page (337 cities, last checked June 2026); Fastly Compute docs and network map (578 Tbps as of 2026-03-31).

Verdict

Cloudflare Workers wins on ecosystem depth, the path of least resistance for JavaScript teams, and longer-running compute. Fastly Compute wins on WebAssembly purity, per-request isolation, and tight coupling to a high-capacity CDN. There is no honest cold-start winner: both eliminate VM-style cold starts, and edge latency is dominated by the network round-trip, not execution. Pick Workers if you want the storage and AI primitives (D1, R2, Durable Objects, Workers AI) and write mostly TypeScript. Pick Fastly if you compile Rust, Go, or C++ to Wasm, want a clean sandbox per request, and your logic lives next to your CDN.

How they actually run your code

Cloudflare's model is V8 isolates. Instead of a virtual machine or container per function, an isolate is created inside an already-running process. The docs are blunt about the payoff: this "eliminates the cold starts of the virtual machine model," and a single runtime instance can hold "hundreds or thousands of isolates, seamlessly switching between them." An isolate starts roughly 100x faster than a Node process and uses an order of magnitude less memory. The economics follow directly. Kenton Varda's security writeup notes that strict process-per-tenant isolation "can easily be 10x" the CPU cost of a shared process, which is why isolates exist at all.

Fastly inverts the primitive. You compile your code to WebAssembly, and Fastly runs it "using the WebAssembly System Interface for each compute request," with "per-request isolation and lightweight sandboxing." In June 2026 the team restated the model plainly: "We isolate every single request execution into its own ephemeral WebAssembly sandbox." A new instance is built and torn down per request rather than persisted and reused.

Here is the asymmetry that matters. Workers does run WebAssembly, but it runs through JavaScript. A Rust Worker is "invoked from a JavaScript entrypoint script which is created automatically for you when using workers-rs," bridged by wasm-bindgen. So "Rust on the edge" with Cloudflare means Rust compiled to Wasm and called from generated JS glue. On Fastly, Wasm is the floor. That difference is invisible in a hello-world and decisive once you care about non-JavaScript languages, binary size, or isolation guarantees. If you are weighing JavaScript runtimes more broadly, the same engine-versus-portability tension shows up in our Bun vs Node.js decision framework.

Cold start and latency: nobody wins cleanly

This is where marketing pages get loud and evidence gets thin. Both platforms eliminate the cold start of the VM model by design, so the interesting question is execution overhead, and the honest answer is that there is no clean independent head-to-head from 2025 or 2026.

The most-cited numbers are vendor figures. Fastly's 2019 Lucet announcement claimed instantiation "in under 50 microseconds, with just a few kilobytes of memory overhead," and contrasted it with V8 at "about 5 milliseconds, and tens of megabytes." Treat that as Fastly measuring Fastly, in the Lucet era, against a general-purpose JS engine. It is directional, not a referee's verdict.

The one real shootout was a public spat. In November 2021 Cloudflare published that "Workers is 196% faster than Fastly's Compute@Edge" on time-to-first-byte across 50 Catchpoint nodes. Fastly rebutted within weeks using "673 Catchpoint nodes instead of 50," a "paid Fastly account," and "a Wasm binary compiled from Rust rather than JavaScript," and reported its network was "nearly twice as fast as Cloudflare Workers in North America and Europe, and 10 times faster in Oceania." An independent observer's take held up better than either: the tests largely "conflate network round trip time with execution at edge time." Edge latency is mostly geography and RTT. The compute layer is a rounding error next to it, which is exactly why optimizing interaction latency is usually about getting close to users, not shaving microseconds off the runtime.

One independent real-world test (Barstool Engineering, December 2021, streaming a 3 MB file) measured Fastly at 38.07 ms TTFB versus Workers at 61.98 ms, with bare EC2 at 77.02 ms. Useful, but a single client location and 100 iterations is a data point, not a trend. The same author noted the practical kicker for portability: "The Fastly implementation is actually identical to the Cloudflare implementation."

The moving target is Cloudflare's side. During Birthday Week 2025 the team reported it "reduced Workers cold starts by 10x by implementing a new 'worker sharding' system that routes requests to already-loaded Workers," and hardened the runtime with "V8 sandboxes and hardware-assisted memory protection keys." If cold start was your reason to avoid Workers, that reason is weaker in 2026 than it was.

Languages and developer experience

If your team writes TypeScript, Workers is the lower-friction choice and it is not close. JavaScript and TypeScript run natively with no Wasm glue, the wrangler CLI is mature, and the runtime is open source as workerd. Local development runs the same workerd binary you deploy to. Python Workers exist but are still in beta behind the python_workers compatibility flag, executed by Pyodide, which is CPython compiled to WebAssembly. Anything else (Rust, C, C++) reaches the edge through the Wasm-via-JS path described above.

Fastly's pitch is the opposite: the runtime is language-agnostic because the contract is Wasm. Official SDKs cover Rust, JavaScript, Go, and C++, and the docs are candid that "Support level per language varies." Go is the sharpest example of the trade-off. The toolchain defaults to TinyGo, which "produces smaller, faster binaries, but its support for Reflection and other Go features is incomplete," or you can target standard Go with GOARCH=wasm and GOOS=wasip1. JavaScript runs on StarlingMonkey, a Bytecode Alliance project. A Python SDK landed in beta on June 2, 2026, with Fastly "cross-compiling standard CPython so it runs inside our isolated WebAssembly sandboxes."

Ecosystem and platform primitives: Workers wins decisively

A runtime is only as useful as the state it can reach. This is the most lopsided dimension in the comparison, and it favors Cloudflare by a wide margin. Workers ships an integrated data and AI platform, most of it generally available: Workers KV, R2 (S3-compatible object storage with no egress fees), D1 (a serverless SQLite database, GA), Durable Objects (compute fused with strongly consistent storage, with SQLite storage now GA), Queues, Hyperdrive, Vectorize, and Workers AI for serverless GPU inference. Containers and Workflows have since gone GA as well.

Fastly's primitive set is deliberately narrower and CDN-shaped: KV Store, Config Store, Secret Store, S3-compatible Object Storage (zero egress within the Fastly network, 11 nines of durability), and Fanout for real-time push. There is no managed relational or SQL database. If your edge function needs a transactional database, a vector store, or model inference colocated with compute, Fastly expects you to bring your own origin. Cloudflare hands it to you as a binding.

Adoption tracks this. Cloudflare publishes named Workers users running real edge logic: Shopify runs checkouts close to customers, Canva uses Workers to "offload Layer 7 logic like redirects, security headers, and other filters to the global network," and DoorDash split CMS traffic 50/50 at the edge. Fastly Compute has its own production stories, often deeper per-customer: Dunelm reported enriching "83 million requests" in its first three weeks live, and Bonnier News migrated off Akamai's proprietary ESI to Rust-based edge rendering on Compute. Both are real. Cloudflare simply has more of them, across more workload types. This is the same edge-rendering pattern that powers islands architecture on the front end.

Production reality: limits and isolation

The limits tell you what each platform is actually for. Fastly caps CPU at 50 ms per request and total runtime at 2 minutes. That is a fast, deterministic edge-logic budget: rewrite a request, stitch a response, enforce a policy, then get out. Workers gives you 30 seconds of CPU time by default on a paid plan (up to a 5-minute max) and no hard wall-clock limit, which makes it viable for genuinely heavy work. Both cap memory at 128 MB per instance.

Isolation is where the runtime bet has teeth. Cloudflare packs many tenants into one OS process behind V8, and the company is unusually candid that this is a sharp edge: "V8 itself cannot defend against Spectre." Working with researchers at TU Graz, Cloudflare produced "a working Spectre variant 1 attack that could leak memory at a rate of 120 bits per hour" across co-located Workers, a result an academic paper independently confirmed. Their defense is layered, not absolute: frozen timers, no concurrency, and Dynamic Process Isolation that reschedules "any Worker with suspicious performance metrics into its own process." The 2025 hardening added V8 sandboxes and memory protection keys. Cloudflare's own conclusion is the fair one to quote: "there is no known complete defense against Spectre, regardless of whether you're using isolates, processes, containers, or virtual machines."

Fastly's per-request Wasm sandbox is a structurally different bet. A new linear-memory sandbox per request narrows what one request can observe from another, and the Wasm boundary is enforced by the compiler and runtime together. That is a real architectural advantage for per-request isolation. It is not a magic Spectre cure, and Fastly does not claim one. The fair read: Fastly's model gives you stronger structural separation between requests by default, Cloudflare's gives you higher density plus a documented, evolving mitigation stack. Neither escapes the underlying hardware problem.

Pricing

Both have converged on usage-based, CPU-time billing with a free tier, so the headline difference is smaller than it looks. Workers charges $5/month per account on the paid plan, including 10 million requests and 30 million CPU-milliseconds, then $0.30 per additional million requests and $0.02 per additional million CPU-ms. Crucially, billing is CPU time, not wall-clock: the pricing page states "No charge or limit for duration," so a Worker blocked on I/O is not burning money. Fastly's free tier is more generous on raw volume (10 million Compute requests and 100 million vCPU-milliseconds free), then meters requests and vCPU-ms on a sliding scale starting at $0.50 per million requests and $0.05 per million vCPU-ms.

Do not pick on sticker price. At low volume both are effectively free, and at high volume the bill is dominated by your actual CPU profile and request count, which only your own workload can tell you.

Migration cost and lock-in

The portable part is the programming model. Both center on a fetch-style request/response handler and the overlapping web-platform APIs now being standardized as the Minimum Common Web Platform API under Ecma TC55, the group formerly known as WinterCG. Fastly's JavaScript runtime explicitly targets that surface. The independent test above found the request-handling code "identical" across both platforms. Moving the compute is rarely the hard part.

Lock-in lives in state, and it is real on both sides. The moment your code calls a platform primitive, it binds to that platform's interface. Cloudflare's Durable Objects are the stickiest dependency in the whole ecosystem: globally unique identity fused with colocated storage is an architecture, not a config value, so leaving means rearchitecting. R2 is the honorable exception, S3-compatible by design, though the zero-egress pricing is itself a retention lever. Fastly's KV, Config, and Secret stores are equally proprietary, while Fanout is a bright spot built on the open GRIP protocol. WebAssembly buys Fastly genuine engine and language portability, but not service portability: a Compute service wired to Fastly's host imports is as bound to Fastly as a Worker is to its bindings.

Pick rules

Pick Cloudflare Workers if:

• Your team writes TypeScript and wants zero Wasm ceremony.
• You need the data and AI platform: D1, R2, Durable Objects, Vectorize, or Workers AI.
• Your functions do real work and need more than a 50 ms CPU budget.
• Breadth of network (337 cities) and a single integrated developer platform matter.

Pick Fastly Compute if:

• You compile Rust, Go, or C++ to WebAssembly and want that to be first-class, not glue.
• Per-request isolation is a hard requirement, not a nice-to-have.
• Your edge logic is fast and deterministic: request shaping, policy, rewriting, personalization.
• Your compute should live in the same POP as your CDN and origin shielding.

Final recommendation

For most teams shipping product, Cloudflare Workers is the safer default. The ecosystem removes entire categories of infrastructure work, the JavaScript path has no friction, and the 2025 cold-start and security investments closed the gaps that used to make Fastly look obviously faster or safer. You trade some structural isolation purity for a platform that does far more out of the box.

Fastly Compute is the better choice when WebAssembly is the point, not a detail. If you are writing performance-sensitive, polyglot edge logic in Rust or Go, you want a fresh sandbox per request, and your compute belongs next to your CDN, Fastly's model is cleaner and more honest about what it is. It asks more of you in exchange for a tighter, more predictable runtime. Choose based on which constraint is load-bearing for your system, not on a benchmark screenshot.

What's next for WebAssembly beyond the browser

The reason this comparison exists at all is that server-side WebAssembly stopped being speculative. WASI 0.2 landed in January 2024, rebased onto the WebAssembly Component Model so interfaces are cross-language and virtualizable. WASI 0.3.0 followed on June 11, 2026, and its headline is significant: "WASI 0.3 is official, and async is now native to WebAssembly Components." Native async closes one of the last gaps that made Wasm awkward for I/O-bound edge workloads.

The Component Model itself is still pre-1.0 and being standardized, but the runtime layer is solid: Wasmtime ships on a real LTS cadence, and the Bytecode Alliance steering it counts both Fastly and Shopify, whose Functions run merchant logic as Wasm, among its members. The broader market is converging too, on active-CPU and scale-to-zero billing that charges only for cycles actually burned. Cloudflare and Fastly disagree on the runtime primitive, but they agree on the direction: code that runs everywhere, isolates cheaply, and bills by the cycle. Wasm is no longer the browser's escape hatch. It is increasingly the substrate the edge runs on.