Fastly Compute: High-Performance Edge with WebAssembly

Fastly Compute^[1] (formerly Compute@Edge) is Fastly’s bet on serious edge computing. While Cloudflare Workers uses V8 isolates and a mature JavaScript ecosystem, Fastly chose pure WebAssembly on its own Lucet/Wasmtime runtime. Two different philosophies with real implications for performance, portability, and ergonomics. This article compares both honestly and explains when Fastly is the right call.

Fastly’s technical bet

Fastly didn’t build its own JavaScript runtime or lean on Node. It chose WebAssembly as the universal compilation target:

• Your code (Rust, Go, AssemblyScript, JS via Javy) compiles to .wasm.

• Fastly deploys the binary to its ~70 global PoPs.

• Each request invokes an ephemeral Wasm module instance.

• Cold start: 35 microseconds (us, not ms). Fastly’s central marketing argument.

The number is real but deserves context: Workers also has sub-5 ms cold start. The gap from 1 ms to 35 µs isn’t visible to end users, but it does allow running thousands of functions per request without accumulated overhead. That matters for complex edge logic, not simple routing.

Supported languages

Four officially supported:

• Rust: first-class citizen. Most mature tooling (fastly crate), most complete documentation.

• JavaScript: supports JS + TypeScript subset, run via Javy^[2], compiled to Wasm ahead-of-time.

• Go: supported via TinyGo. Limitations vs standard Go.

• AssemblyScript: TypeScript subset that compiles directly to Wasm.

For new projects, Rust is the clear recommendation. For pure-JS teams, support is solid but doesn’t match Workers’ ergonomics, where the npm ecosystem is far more tightly integrated.

Execution model

Each request lifecycle in Fastly Compute:

• Arrives at the nearest PoP to the user.

• Wasm module is instantiated (35 µs cold start).

• Handler executes with access to request/response/stores.

• Instance is destroyed: stateless execution by default.

• Response is sent to the client.

No shared state between requests within the same process. Fastly prioritises determinism and strong isolation over state convenience. This is a deliberate tradeoff, not a limitation.

Rust hello world

use fastly::http::{Method, StatusCode};
use fastly::{Error, Request, Response};

#[fastly::main]
fn main(req: Request) -> Result<Response, Error> {
    match (req.get_method(), req.get_path()) {
        (&Method::GET, "/") => Ok(Response::from_status(StatusCode::OK)
            .with_body("Hello from Fastly Compute")),
        _ => Ok(Response::from_status(StatusCode::NOT_FOUND)),
    }
}

Deploy with one command: fastly compute publish.

The CLI workflow is polished: local builds, preview deployments, and rollback, all via the fastly command. For the broader context of WebAssembly as an open standard, see WebAssembly and components and WASI preview 2.

Fastly Compute vs Cloudflare Workers

For compute-intensive code in Rust/Go, Fastly performs better. For JS/TS apps with npm ecosystem, Workers is more productive. Cloudflare has a clear advantage in PoP count and entry pricing.

Where Fastly clearly wins

Scenarios where Fastly is the natural choice:

• Portable Rust code: if you already have critical logic in Rust, porting is natural and requires no translation overhead to JS.

• Enterprise compliance and control: Fastly has a more established track record in regulated industries.

• Integration with Fastly CDN: for teams already on Fastly, Compute is the natural evolution without adding a new vendor.

• Predictable performance: the sub-millisecond cold start matters for high-concurrency workloads where a single request can fire more than one function.

• Serious custom edge logic: complex A/B tests with deterministic logic, HTML rewriting, image transforms.

Where Workers wins

Cloudflare Workers dominates in:

• JS ecosystem: npm packages with Cloudflare adaptations work directly.

• Durable Objects + KV + D1: Workers has more ready-made primitives for stateful edge.

• Entry pricing: starting is 10x cheaper than Fastly.

• Geographic coverage: ~300+ PoPs vs ~70.

• Community resources: more public examples, tutorials, and third-party tooling.

Common real-world patterns

• API gateway: validate auth, transform requests, route by feature flags.

• Image optimisation: resize and optimise on-the-fly at the edge.

• HTML rewriting: inject consent banners or personalised content.

• A/B testing: split traffic with deterministic logic based on headers or cookies.

• Geo-based routing: serve different content by country or region.

For pure static content, a conventional CDN is enough. Compute is for logic that needs to live at the edge, cutting round-trips to the origin.

Realistic costs

Fastly Compute:

• Essential plan: $50/month includes 1M requests.

• Additional requests: $0.50 / 1M.

• Compute time: separate charge per milliseconds used.

Cloudflare Workers:

• Free tier: 100k requests/day.

• Paid plan: $5/month includes 10M requests.

• Additional: $0.30 / 1M.

For low-traffic workloads, Workers is clearly cheaper. For high-traffic deployments with complex logic, Fastly can be competitive thanks to the efficiency of the Wasm runtime.

Current limitations

• Limited binary size (~100 MB). Large apps compiled to Wasm may hit this ceiling.

• Max request duration: ~60s.

• No persistent native WebSockets. Workers Durable Objects wins here.

• Limited Wasm debugging compared to JS devtools.

• Smaller community and fewer public examples than Workers.

WebAssembly at the edge: the trend

Beyond Fastly, the Wasm+edge pattern is solidifying across the industry. Cloudflare has Workers for Platforms with optional Wasm support. Wasmer Edge is betting on distributed edge Wasm. Shuttle.rs offers Rust full-stack with edge deployment built in.

Fastly was the pioneer in this space; others are following. The trend is real regardless of which platform you end up on.

Conclusion

Fastly Compute is a serious technical bet on WebAssembly at the edge. For compute-intensive workloads, complex Rust logic, or teams already on Fastly CDN, it is the more performant option. For the median case of "edge JS logic with npm ecosystem and low entry price", Cloudflare Workers remains more practical.

The choice isn’t ideological. It’s contextual: what language, what team, what scale, what compliance.

Frequently asked questions

How much does Fastly Compute cost compared to Cloudflare Workers?

Fastly Compute's Essential plan is $50/month including 1M requests, $0.50 per additional million, plus a separate charge per milliseconds of compute time. Cloudflare Workers has a free tier of 100k requests/day and a $5/month plan with 10M requests and $0.30 per extra million. For low-traffic workloads Workers is clearly cheaper; for high-traffic deployments with complex logic Fastly can be competitive thanks to the efficiency of the Wasm runtime.

Can I use JavaScript on Fastly Compute, or only Rust?

You can. The four officially supported languages are Rust, JavaScript, Go via TinyGo, and AssemblyScript. JavaScript support is a JS and TypeScript subset run via Javy and compiled to Wasm ahead-of-time; TinyGo carries limitations versus standard Go. For new projects Rust is the clear recommendation, with the most mature tooling in the fastly crate; for pure-JS teams the support is solid but does not match Workers' npm ergonomics.

What limitations of Fastly Compute should I know before choosing it?

Binary size is limited to about 100 MB, maximum request duration is around 60 seconds, and there are no persistent native WebSockets, where Workers Durable Objects wins. Debugging is limited because Wasm stack traces are not as clear as JS devtools, it has around 70 PoPs versus Cloudflare's 300+, and there is a smaller community with fewer public examples.

Sources

1. Fastly Compute
2. Javy