Fastly Compute@Edge

What Fastly Compute actually is

Fastly Compute is a WebAssembly-based serverless platform that runs your code inside Fastly's edge network — the same network described in our Fastly CDN review. The product began life as Compute@Edge, launched in private beta in 2019 and announced publicly on November 6, 2019, and has since been renamed to simply Fastly Compute. The premise: compile your application to WebAssembly, deploy it to a hundred-plus points of presence, and let each request execute in its own isolated sandbox close to the user, with no containers to manage and no regions to pick.

The architecture is genuinely different from the big serverless platforms, and it is worth understanding before comparing prices. Fastly compiles your code to a WebAssembly module and executes it with Wasmtime (earlier generations used Fastly's own Lucet runtime). In the default configuration each incoming request creates a fresh function instance — a new sandbox that is destroyed when the request finishes. That per-request isolation is why Fastly advertises essentially no cold starts: the company claimed a 35.4 microsecond environment startup at beta, roughly 100x faster than the container-based serverless offerings of the time, and marketed a zero-cold-start JavaScript runtime when JavaScript support arrived in July 2021. An opt-in reusable-sandbox mode exists for workloads where repeated initialization overhead matters more than per-request isolation.

Language support is WebAssembly-shaped. Fastly publishes official SDKs for Rust, JavaScript, Go and C++, and community or custom SDKs can target anything that compiles to the right WASI target. The platform is intentionally language-agnostic at every layer, and you can pull dependencies from your normal package registry. Alongside compute, Fastly offers edge data stores — KV Store, Secret Store and Object Store — plus Fanout for one-to-many messaging, dynamic configuration and real-time log streaming, all of the same platform family.

Pricing: what you really pay

Fastly Compute pricing is usage-based with generous monthly free allowances, and it changed recently in a direction we like: the old "duration" meter (memory multiplied by time, billed in GB-seconds) was removed for new purchases, so new Compute billing focuses strictly on requests and vCPU consumption. Every month the first 10 million Compute requests and the first 100 million Compute vCPU-milliseconds are free. Beyond that, Compute requests are $0.50 per million in the 10 million to 500 million band, sliding down with volume to $0.20 per million beyond 500 billion; vCPU-milliseconds are $0.05 per million in the first paid band, declining to $0.02 per million beyond 5 trillion. KV Store, Secret Store and Fanout have their own free allotments.

Because Compute rides on the Fastly account, the shared free tier applies too: 100 GB of bandwidth, 500,000 CDN requests and TLS for five domains free each month, with delivery bandwidth then billed per GB per region ($0.12 in North America and Europe in the first band, $0.08 beyond 10 TB, up to $0.28 in Africa, India and South Korea). The free tier requires a valid credit card. Note two account wrinkles: deploying your first Compute service starts a free trial with lower resource limits, and accounts created before November 4, 2025 remain on legacy pricing of $50 per month plus usage — so "what Fastly costs" depends partly on when you signed up. Charges for the old duration metric only still apply to customers who bought Compute on or before March 17, 2026 with that metric on their service order.

The pricing model rewards efficient code in a way most serverless platforms do not: because you are billed for vCPU milliseconds rather than provisioned memory-time, an optimized routine is literally cheaper than a sloppy one. In our view, that is the right incentive structure, and combined with the free allowances it makes Fastly Compute one of the cheaper places to run small-to-mid edge workloads — until traffic becomes large enough that per-request rates dominate.

Performance & infrastructure

Compute runs on the Fastly edge network: over 100 city-level points of presence across North America, South America, Europe, Africa, Asia and Australia/New Zealand — including a notably deep Indian footprint — with 622 Tbps of connected global capacity as of June 30, 2026. Fastly's deliberate "fewer, bigger PoPs" design (high-density sites near major internet exchanges, SSD-based servers, Tier 1 transit) applies to compute as much as to caching. There is no region selection in the usual sense: your service deploys globally and requests execute at whichever PoP serves the user. Supporting infrastructure includes KV Store for key-value state, Secret Store for credentials, Object Store for blobs, Fanout for pub/sub-style streaming, and real-time log shipping to external observability systems.

The execution model is the security story. Each request runs in its own WebAssembly sandbox with a "burn-after-reading" approach to request memory, which removes whole classes of data-leakage and use-after-free problems that come with reusable container isolates. Per-request isolation and lightweight sandboxing are the documented design goals, and the platform explicitly forbids cryptocurrency mining. Protocol support matches the CDN: HTTP/1.1, HTTP/2, HTTP/3 with QUIC, TLS 1.0 through 1.3, and IPv6 dual-stack via Fastly's service maps and peering on AS 54113.

Reliability inherits from the network that serves roughly 5 trillion requests a day for customers including GitHub and the New York Times. We have not benchmarked Fastly Compute ourselves — startup and latency figures here (35.4 microseconds at beta, sub-millisecond TTFB on the CDN side) are vendor measurements — and our benchmarks page covers only what we tested directly. But the underlying isolation architecture is sound and the operational record of the network is public.

Where it falls short

The honest first complaint is the WebAssembly toolchain. Compiling to WASM with the right WASI target, working within capability-based sandboxing, and handling the fact that not every library compiles cleanly adds friction that plain JavaScript or Python functions on competing platforms simply do not have. Rust is the smoothest path; JavaScript is supported but constrained compared to a Node runtime; anything outside the official SDK list means you are a pioneer. "WASM compilation adds complexity" is the polite phrasing — budget real developer time for the first deploy.

Second, resource limits and feature gating differ by account type. Free accounts have lower limits and some features require contacting support; the first deploy triggers a trial state that is not intended for production traffic; and the two legacy pricing regimes make cost comparison across teams awkward. For production, expect a conversation with Fastly rather than pure self-serve.

Third, the ecosystem around edge state is Fastly-specific. KV Store, Secret Store and Fanout are proprietary APIs, not S3-compatible or Redis-compatible interfaces, so a Compute-centric architecture ties its state layer to Fastly. That is a reasonable trade for speed, but it is a real lock-in vector that teams should price explicitly.

Finally, per-request plus per-vCPU pricing is cheap at small scale and less obviously cheap at massive request volumes with heavy CPU work — model the vCPU band, not just the request count, before celebrating the free tier.

Who should pick this

We would pick Fastly Compute for latency-sensitive request logic that belongs at the edge: personalization and geofencing at the CDN layer, authentication and header logic, API gateways and request routing, streaming fan-out, image and content transformation, and small full applications where sub-millisecond startup and per-request isolation matter. Teams already on Fastly's CDN get the most from it — one control plane, one network, one log stream — and Rust-fluent teams will feel most at home. Our pick for security-conscious edge workloads where sandbox isolation is a requirement rather than a feature.

We would skip it for long-running compute (this is not a container platform), for teams without WASM experience and a deadline, for workloads needing S3-compatible or Redis-compatible state, and for anything that wants straightforward per-region deployment. If your serverless usage is short request handlers and you value zero cold starts and isolation over ecosystem breadth, this is one of the strongest options available.

Key takeaways

• WebAssembly serverless on Fastly's edge (100+ PoPs, 622 Tbps): code runs at whichever PoP serves the user, no region to pick
• Formerly Compute@Edge (beta November 2019); executes on Wasmtime with official SDKs for Rust, JavaScript, Go and C++
• Per-request sandbox isolation with fast startup (35.4 microsecond environment startup claimed at beta) — effectively no cold starts
• New billing is requests + vCPU only: 10 million requests and 100 million vCPU-milliseconds free monthly, then $0.50 per million requests and $0.05 per million vCPU-milliseconds, with volume declines
• Edge state is Fastly-specific (KV Store, Secret Store, Object Store, Fanout) — not S3-compatible, a real lock-in consideration
• Strong fit for security-conscious, latency-sensitive edge logic and existing Fastly customers; wrong fit for long-running compute or WASM newcomers on a deadline

Sources

• https://www.fastly.com/pricing
• https://docs.fastly.com/products/compute
• https://www.fastly.com/documentation/guides/compute/getting-started-with-compute/
• https://www.fastly.com/blog/shrink-your-bill-with-efficient-software
• https://fastly.com/press/press-releases/fastly-expands-serverless-capabilities-launch-compute-edge
• https://fastly.com/press/press-releases/fastly-launches-new-era-of-highly-secure-serverless-javascript-with-zero
• https://fastly.com/blog/join-the-beta-new-serverless-compute-environment-at-the-edge
• https://www.fastly.com/network-map
• https://www.fastly.com/blog/ipv6-fastly
• https://en.wikipedia.org/wiki/Fastly