Cloudflare Workers charges $5 a month for 10 million requests and bills zero dollars for data transfer. Fastly Compute, the company’s WebAssembly-based rival, no longer publishes a self-serve number for any of that. As of October 2026, Fastly’s pricing page has quietly dropped Compute’s unit pricing entirely, pushing developers who want a quote toward a sales call instead of a calculator. That single change reshapes how engineering teams should think about choosing between the two platforms this year.
Both products solve the same basic problem: run application code at the network edge, close to users, without managing servers. Both avoid the multi-second cold starts that plague traditional container platforms. But they get there through different sandboxing technology, charge for usage in different units, and target different kinds of teams. This comparison pulls specs, pricing, and benchmark data from official documentation, independent latency tests, and named case studies to help engineering leads pick the right one for an October 2026 migration.
Cloudflare Workers vs Fastly Compute: the 60-second verdict
Cloudflare Workers runs JavaScript and TypeScript inside V8 isolates, the same lightweight sandboxing technology that powers Chrome tabs. Fastly Compute runs code compiled to WebAssembly through a Wasmtime-derived runtime, favoring Rust, Go (via TinyGo), and JavaScript compiled down to Wasm modules. Cloudflare publishes transparent, self-serve pricing with a $5 monthly floor and no egress charges. Fastly, by contrast, retired its public per-request Compute pricing in 2026 and now routes most serious usage through a sales quote.
For a team that wants to sign up with a credit card tonight and ship a Worker before lunch, Cloudflare Workers is the obvious starting point. For a team already running Fastly’s CDN at scale, with an existing account team and negotiated bandwidth rates, Fastly Compute slots into that relationship without adding a second vendor. Neither platform has a definitively faster runtime once you account for real network latency rather than isolated cold-start microbenchmarks, a point worth holding onto before any vendor’s marketing deck claims otherwise.
What Cloudflare Workers actually is
Cloudflare Workers is Cloudflare’s serverless execution environment, built on V8 isolates rather than virtual machines or containers. Instead of spinning up a new process for every request, Cloudflare runs many isolated JavaScript contexts inside a single, already-running process on each edge server. That architecture is the reason Workers can start a new instance in a fraction of the time a container takes to boot. Cloudflare’s own pricing documentation confirms the current Workers Free plan allows 100,000 requests per day with 10 milliseconds of CPU time per invocation, while the Workers Paid plan starts at $5 per month per account and includes 10 million requests plus 30 million CPU milliseconds before overage charges apply, according to Cloudflare’s official pricing page.
Workers supports JavaScript and TypeScript natively, plus WebAssembly modules for teams that want to bring compiled code into the same runtime. Memory is capped at 128 MB per isolate on both the free and paid tiers. CPU time, not wall-clock duration, is what gets billed, so a Worker that spends most of its time waiting on a fetch to an origin server costs very little even if the request itself takes a while to resolve. As of September 4, 2026, Cloudflare also removed the separate compressed bundle-size limits that used to differentiate Free and Paid plans, letting both tiers deploy uncompressed bundles up to 64 MiB, per Cloudflare’s platform limits documentation.
The platform extends well past raw compute. Workers KV, Durable Objects, D1 (a SQLite-compatible edge database), R2 object storage, Queues, and Hyperdrive all bolt onto the same billing account, and each has its own separate pricing. That breadth is Cloudflare’s biggest practical advantage: a team can build a full stateful application at the edge without stitching together five different vendors.
What Fastly Compute actually is
Fastly Compute (formerly Compute@Edge) takes a different technical bet. Rather than isolates inside a shared JavaScript engine, Fastly runs each request through a sandboxed WebAssembly module via a Wasmtime-based runtime, as described on Fastly’s edge compute product page. That design is language-agnostic by nature: Rust, Go compiled through TinyGo, JavaScript compiled to Wasm, and AssemblyScript are all first-class options, since they all eventually produce the same portable binary format that the runtime executes.
The tradeoff shows up in developer experience rather than raw speed. Shipping a Rust or Go function to Fastly Compute usually means compiling locally before deploy, a step that JavaScript-first Workers developers skip entirely. In exchange, Fastly Compute inherits Wasm’s strict capability-based sandboxing, which some security teams view as a cleaner isolation boundary than a shared V8 process, even though Cloudflare’s isolate model has its own strong security track record.
Fastly’s documentation describes Compute billing as based on request volume, compute duration, and CPU time, layered on top of whatever CDN delivery plan a customer already has. That is where 2026 brought a real shift: Fastly’s community forums and legacy pricing pages confirm that the older self-serve numbers, $0.50 per million Compute requests and $0.000035 per GB-second of compute duration, are now explicitly labeled legacy 2025 pricing. The current Fastly pricing page does not publish a replacement self-serve number for any of those three metrics, meaning most new Compute customers now negotiate pricing directly with a Fastly account team rather than reading it off a page.
Specs comparison: Cloudflare Workers vs Fastly Compute
| Category | Cloudflare Workers | Fastly Compute |
|---|---|---|
| Sandbox technology | V8 isolates | WebAssembly (Wasmtime-based runtime) |
| Primary languages | JavaScript, TypeScript, Wasm modules | Rust, Go (TinyGo), JavaScript-to-Wasm, AssemblyScript |
| Memory per isolate/instance | 128 MB | Varies by plan; not self-serve published for 2026 |
| Free tier requests | 100,000/day | Not published as a guaranteed numeric tier in 2026 |
| Paid plan entry price | $5/month per account | Not published; quote-based |
| Included monthly requests (paid) | 10 million | Not published |
| Overage request pricing | $0.30 per additional million | Not published (2025 legacy: $0.50/million) |
| CPU time included (paid) | 30 million ms/month | Not published |
| Max CPU time per invocation | 5 minutes (default 30 seconds) | Varies by deployment |
| Data transfer / egress charge | None on base plan | Bundled into existing Fastly delivery plan |
| Uncompressed bundle size limit | 64 MiB (both Free and Paid, since Sept. 4, 2026) | Varies by language toolchain |
| Companion data/storage products | KV, D1, Durable Objects, R2, Queues, Hyperdrive | Primarily CDN caching, config store, edge dictionaries |
| Deployment model | Single script per Worker, instant global propagation | Compiled Wasm binary, build step required for most languages |
Pricing comparison in detail
Cloudflare’s pricing model rewards predictability. The example Cloudflare publishes on its own pricing page walks through a Worker serving 15 million requests a month at an average of 7 milliseconds of CPU time per request: a $5 base subscription, $1.50 for the 5 million requests above the included 10 million, and roughly $1.50 more for the CPU time beyond the included allotment, landing just over $8 a month total for that workload. That kind of line-item transparency is rare in cloud infrastructure pricing and makes budgeting a Workers deployment almost mechanical.
Fastly’s pricing story in 2026 is messier, and that is itself a meaningful data point for buyers. The legacy Compute pricing that circulated through 2025, $0.50 per million requests and $0.000035 per GB-second of duration, has been pulled from Fastly’s current public pricing page. Fastly’s own community discussion confirms Compute pricing was removed from self-serve view, and that developer trial access should not be mistaken for a permanent free tier. In practice, that means a team evaluating Fastly Compute today needs an actual conversation with a Fastly account representative before they can model a monthly bill, which adds procurement time that a scrappy side project or early-stage startup may not want to spend.
| Tier | Cloudflare Workers | Fastly Compute |
|---|---|---|
| Free / trial | 100,000 requests/day, 10ms CPU/invocation, 128MB memory | Developer trial access only, no guaranteed numeric allowance |
| Entry paid tier | $5/month minimum, 10M requests + 30M CPU-ms included | Custom quote, bundled with CDN delivery plan |
| Overage: requests | $0.30 per additional million | Not published (legacy 2025 rate: $0.50/million) |
| Overage: compute | $0.02 per additional million CPU-ms | Not published (legacy 2025 rate: $0.000035/GB-second) |
| Data transfer/egress | $0 on base plan | Covered by delivery bandwidth tiers (0-100GB/month free on CDN) |
| Enterprise | Custom usage model via account manager | Custom quote, standard for most serious Compute usage |
One nuance worth flagging for anyone pricing out a real application on Workers: the $5 and the per-request numbers above cover compute only. Durable Objects, D1, R2, and Queues each carry separate line items, so a stateful application’s real bill will run higher than the base Workers calculation suggests. Cloudflare’s documentation is explicit about this, and it is the kind of detail that trips up teams building their first cost estimate.
Benchmark data: what independent tests actually show
Performance claims are where edge compute marketing gets slippery, so it is worth walking through what three separate sources actually measured rather than repeating a single vendor’s number. BlazingCDN published a real-world latency test in May 2025, updated through June 2026, that reported Fastly Compute cold starts as low as 35 microseconds at the 50th percentile for a small 3KB function, rising to 210 microseconds for a much larger 780KB function. The same test cited an equivalent Cloudflare Workers function at roughly 1.2 milliseconds at the median. That looks like a decisive win for Fastly, until a second BlazingCDN article, run later in 2026 across eight global regions with 10,000 requests per region, found Fastly’s own cold-start median ranging from 4.7 milliseconds in Frankfurt to 12.6 milliseconds in Johannesburg, with warm median latency between 6.2 and 21.3 milliseconds depending on region.
The gap between those two BlazingCDN results, microseconds in one test and single-digit milliseconds in another, almost certainly comes down to what each test actually measured: raw Wasm module initialization versus a full end-to-end request that includes network hops and regional routing. A third source, an internal benchmark from KGA-IT published in April 2026 testing both platforms across Tokyo, Singapore, and Mumbai at 1,000 requests per second for an hour, found the two platforms within a few tenths of a millisecond of each other on P99 cold starts, with simple JSON-response latency landing at 4.8 milliseconds for Cloudflare versus 5.2 milliseconds for Fastly in the Tokyo test.
A separate technical write-up by engineer Abhi Panseriya, published in June 2026, makes the honest point directly: no clean, methodologically rigorous, independent 2025-2026 head-to-head benchmark between the two platforms currently exists. The only older apples-to-apples data point referenced dates back to a December 2021 Barstool Sports engineering test streaming a 3MB file, where Fastly logged 38.07 milliseconds time-to-first-byte against 61.98 milliseconds for Workers, a result that is five years old and specific to one streaming workload, not a general verdict on either platform in 2026.
| Source | Date | Finding |
|---|---|---|
| BlazingCDN, small-function latency test | May 2025, updated June 2026 | Fastly 35µs-210µs cold start vs Workers ~1.2ms (3KB-780KB functions) |
| BlazingCDN, 8-region delivery test | May 2025, updated Oct. 2026 | Fastly cold start 4.7ms-12.6ms median across regions; warm 6.2ms-21.3ms |
| KGA-IT, Edge Platform Benchmark | April 2026 | Workers under 5ms P99; Fastly 0.3ms median/~5ms P99; JSON response 4.8ms vs 5.2ms (Tokyo) |
| Abhi Panseriya technical review | June 2026 | No clean independent 2025-2026 benchmark exists; cites 2021 Barstool test as the only older data point |
The honest takeaway: both platforms deliver cold starts measured in single-digit milliseconds or less for simple functions, and the difference between them in most real applications will be swamped by network latency, cache state, and however far a user sits from the nearest point of presence. Anyone who tells you one platform is “faster” without specifying the exact workload and region is oversimplifying.
Real-world examples: who runs what
Cloudflare’s official case studies document several companies running production logic on Workers, not just routing traffic through Cloudflare’s CDN. Shopify’s case study describes using Workers and Workers for Platforms to personalize storefronts and build, deploy, and scale commerce applications like shopping carts and payment flows closer to shoppers. Ninetailed built a low-latency personalization engine where Workers evaluates visitor profile and event data at the edge, pairing it with Cloudflare’s HTML Rewriter to personalize otherwise static, cached pages without a round trip to origin. Discord’s case study details using Cloudflare Workers as part of its edge request-handling infrastructure to keep its chat platform responsive at global scale.
On the Fastly side, LaunchDarkly’s customer story covers Flagbearer@Edge, a system that moves feature-flag evaluation onto Fastly Compute to cut the latency of flag initialization for applications that need to check flag state on every request. Fastly’s broader customer directory lists additional Compute deployments across media, e-commerce, and ad-tech, including implementations of the IAB Tech Lab’s Trusted Server framework, which uses Compute to run server-side advertising logic while keeping monetization control with publishers rather than third-party ad servers.
The pattern across both sets of examples is consistent: companies adopt edge compute when a specific piece of logic, personalization, flag evaluation, ad serving, request transformation, genuinely benefits from running at the network edge instead of a centralized origin. Neither platform’s customer list suggests teams are migrating entire application backends wholesale. The sweet spot for both is a well-scoped slice of logic.
Developer experience and language support
Cloudflare Workers is built for a JavaScript-first team. Wrangler, Cloudflare’s CLI, handles local development, testing, and deployment with minimal setup, and most Workers ship as plain TypeScript with no separate compile step beyond what any modern JS toolchain already does. Node.js compatibility has expanded over the past two years, letting many existing npm packages run unmodified, though Workers is still not a drop-in replacement for a full Node server and some packages that rely on native bindings or filesystem access will not work.
Fastly Compute asks more of the developer up front. Shipping Rust or Go code means setting up a cross-compilation toolchain targeting Wasm before every deploy, and debugging a Wasm module’s behavior in production can be less intuitive than stepping through plain JavaScript. The payoff is portability and language choice: a team with existing Rust expertise, or one that specifically wants the stronger sandboxing guarantees of WebAssembly’s capability model, gets a cleaner fit on Fastly than it would forcing that code into a JS-centric runtime.
For teams without a strong language preference, the practical deciding factor usually comes down to who’s already paying the CDN bill. A company with an existing Fastly delivery contract and negotiated bandwidth rates has a real incentive to keep Compute inside that relationship. A company with no existing vendor lock either way will almost always find Cloudflare’s self-serve, credit-card-signup flow faster to get something shipped.
Where both platforms sit in the broader edge compute market
Cloudflare Workers and Fastly Compute are not the only two options for running code at the edge, and framing the decision as a pure binary undersells how crowded this market has gotten. AWS offers Lambda@Edge and CloudFront Functions, both tied tightly to the rest of AWS’s ecosystem and billing. Deno Deploy and Vercel’s Edge Functions target a narrower, more frontend-focused audience, usually teams already deployed on those platforms for a full-stack JavaScript app rather than teams picking an edge runtime as a standalone infrastructure decision. None of those alternatives match Cloudflare’s combination of a mature isolate runtime, a deep companion product suite, and self-serve pricing, which is part of why Workers keeps coming up as the default comparison point for Fastly Compute specifically.
What makes the Workers-versus-Compute comparison more interesting than, say, Workers versus Lambda@Edge, is that both companies built their reputations on CDN and network infrastructure before either offered programmable compute. Fastly in particular has spent years positioning itself around request-level control and real-time purging, and Compute is a natural extension of that story, a way to let the same engineers who configure VCL-style request logic write actual application code instead. Cloudflare’s path was different: Workers grew out of a company that already had a global network of data centers built to absorb DDoS traffic, and the leap to “let customers run their own code on that network” followed from infrastructure Cloudflare had already built for other reasons. Understanding that history helps explain why Cloudflare’s product surface is broader (it was building a platform) while Fastly’s remains more tightly scoped around request/response manipulation (it was extending a CDN).
Observability, debugging, and local development
How easy a platform is to debug in production often matters more day-to-day than raw cold-start numbers, and this is an area where the two platforms diverge in ways worth testing before committing. Cloudflare’s Wrangler CLI includes a local dev mode that simulates the Workers runtime on a developer’s machine, plus `wrangler tail` for streaming live logs from a deployed Worker without needing a separate logging pipeline. Cloudflare also exposes structured logging and exception tracking through its dashboard, and third-party observability vendors have built Workers-specific integrations given how widely the platform is used.
Fastly’s tooling for Compute includes a local test server through the Fastly CLI, which runs the compiled Wasm module locally before deploy, closely mirroring how the module will behave in production since it is running the same binary rather than a simulated environment. That can be an advantage: what runs locally is closer to what runs in production, with fewer “works locally, breaks at the edge” surprises tied to runtime emulation gaps. The cost is the build step itself. A JavaScript change on Workers is visible the moment Wrangler finishes an upload. A Rust change on Compute has to clear a full compile cycle first, which adds seconds to minutes to every iteration depending on the size of the codebase and the toolchain’s cache state.
Teams evaluating either platform for a production workload should spend an afternoon actually debugging a deliberately broken deployment on each before signing anything long-term. Reading a pricing page tells you what something costs. Reproducing an incident and finding the failing request in logs tells you how much time you’ll lose the first time something breaks in production at 2 a.m.
Vendor lock-in and exit considerations
Lock-in risk looks different on each platform. Cloudflare Workers code that sticks to plain JavaScript/TypeScript and the Fetch API is relatively portable in principle, but the moment a project reaches for Durable Objects, D1, or Workers KV for state, that state layer has no drop-in equivalent anywhere else. Migrating off Workers at that point means rebuilding the data layer, not just swapping where the request handler runs, and that is a materially bigger project than most teams budget for when they first adopt the platform.
Fastly Compute’s lock-in risk is more about the language investment than the storage layer, since Fastly’s companion state tools (config store, edge dictionaries) are narrower in scope than Cloudflare’s. A team that builds a substantial Rust or Go codebase targeting Fastly’s specific Wasm interfaces will need real rewrite time to move that logic elsewhere, even though the underlying language itself is portable. In both cases, the practical lesson is the same: keep the edge layer thin and stateless wherever the use case allows it, and treat deep integration with either vendor’s state or storage products as a deliberate, hard-to-reverse decision rather than a default.
Pros and cons
Cloudflare Workers
- Transparent, published, self-serve pricing with a predictable $5/month floor
- No data transfer or egress charges on the base plan
- Deep companion product lineup (KV, D1, Durable Objects, R2, Queues) for stateful apps
- JavaScript/TypeScript-first, minimal build tooling for most use cases
- Instant global deployment with no regional configuration required
- 128MB memory ceiling can be restrictive for memory-heavy workloads
- Companion products add separate line items that complicate total cost estimates
Fastly Compute
- WebAssembly sandboxing appeals to security-conscious teams and multi-language shops
- Strong fit for teams already running Fastly’s CDN and delivery contracts
- Rust, Go, and AssemblyScript support beyond JavaScript
- Reported sub-millisecond module initialization in some third-party tests for small functions
- 2026 pricing opacity: no published self-serve numbers, requires a sales conversation
- Build/compile step adds friction for teams used to deploy-on-save workflows
- Smaller companion ecosystem for edge storage/state compared to Cloudflare’s product suite
5 use cases and which platform fits
1. API gateway and request transformation. Both platforms handle this well, but Cloudflare Workers’ tight integration with KV for config lookups and its zero egress charge make it the cheaper default for high-volume API proxying.
2. A/B testing and personalization at the edge. Cloudflare has the stronger documented track record here, with Ninetailed’s production deployment showing exactly this pattern using Workers plus HTML Rewriter.
3. Feature flag evaluation. LaunchDarkly’s own Flagbearer@Edge system runs on Fastly Compute, making it the platform with the clearest named precedent for this specific workload.
4. Server-side ad serving with publisher-controlled monetization. The IAB Tech Lab’s Trusted Server implementations on Fastly Compute point to that platform for teams building ad-tech infrastructure that needs to run close to the CDN layer already serving the ad creative.
5. Stateful edge applications needing a database. Cloudflare’s D1 and Durable Objects give Workers a meaningfully easier path to building something closer to a full application at the edge, rather than a pure request-transformation layer.
Migration guide: moving between Cloudflare Workers and Fastly Compute
Teams migrating in either direction should budget real engineering time, not a weekend project. The core logic rarely ports directly because the two platforms expose different request/response APIs and different runtime primitives.
- Audit current usage. Pull 30 days of request volume, average CPU time per request, and peak concurrency from your existing platform’s dashboard before estimating a new bill on the other side.
- Map companion services. List every KV, D1, Durable Object, or Fastly config-store/dictionary dependency. These rarely have a 1:1 equivalent on the other platform and often require a redesign, not a straight port.
- Rewrite the request handler. Moving from Workers to Compute means translating the Fetch API-style handler into Compute’s Rust, Go, or JS-to-Wasm request model. Moving the other way means flattening Wasm-specific logic back into a standard JavaScript fetch handler.
- Set up the build pipeline. Compute deployments headed toward Rust or Go need a cross-compilation toolchain and CI step that most Workers-only teams have never had to maintain. Budget time for this even if the team has used Rust before.
- Run a shadow deployment. Route a small percentage of production traffic to the new platform behind a feature flag or weighted DNS split before cutting over fully, so latency and error-rate regressions show up before they hit all users.
- Re-benchmark in your own regions. Given how much the third-party benchmark numbers disagree with each other, run your own latency test from your actual user geography rather than trusting a vendor’s cold-start claim.
- Get real pricing in writing. Because Fastly’s Compute pricing is no longer self-serve in 2026, get a written quote covering request volume, compute duration, and bandwidth before committing, and compare it against Cloudflare’s published calculator math for the same workload.
- Cut over gradually. Shift traffic in stages (10%, 50%, 100%) over one to two weeks, watching error rates and P99 latency at each step, with a fast rollback path to the original platform if something regresses.
Security and reliability considerations
Both platforms rely on sandboxing to isolate untrusted code, just through different mechanisms. V8 isolates separate JavaScript execution contexts within a shared process, a model Cloudflare has run at massive scale for years. WebAssembly’s capability-based model restricts what a module can access by default, which some security teams view as a structurally tighter default than a shared-process isolate, though both have held up well in production at scale.
Neither Cloudflare nor Fastly has published a detailed 2026 incident timeline specific to their Compute products in the material available for this comparison, and it would be a mistake to infer platform reliability purely from the absence of a headline outage. A useful distinction for any team doing due diligence: a CDN-wide control-plane incident is different from a runtime-specific outage affecting only Workers or only Compute, and a provider can experience one without the other. Check each vendor’s official status history directly before signing a contract that assumes a specific uptime figure.
Cost modeling: a realistic workload comparison
Using Cloudflare’s own published example, a Worker serving 15 million requests a month at an average of 7 milliseconds of CPU time per request costs about $8.00: the $5 base, $1.50 for 5 million requests over the included 10 million, and roughly $1.50 for CPU time over the included 30 million milliseconds. Scale that same workload to 100 million requests a month at the same CPU profile, and the request overage alone grows to roughly $27 above the base plan, before accounting for CPU time overage, still a figure a finance team can compute from a spreadsheet without calling anyone.
Modeling the equivalent workload on Fastly Compute in 2026 is not something a team can do from public documentation alone. The legacy 2025 rate card, $0.50 per million requests and $0.000035 per GB-second of compute duration, is explicitly marked legacy and not guaranteed to reflect current pricing. Any team that needs budget certainty before committing engineering time to a Fastly Compute migration should treat “get a written quote” as step one, not an afterthought, because the public numbers that used to make this comparison straightforward no longer exist.
The verdict
For most teams evaluating edge compute for the first time in late 2026, Cloudflare Workers is the stronger default choice. The pricing is public, the onboarding takes minutes, the companion product ecosystem (KV, D1, Durable Objects, R2) covers most stateful use cases without adding a second vendor, and the JavaScript-first developer experience matches what most web teams already know. The $5/month floor with 10 million included requests and zero egress charges is difficult to beat on pure predictability.
Fastly Compute earns its place in a narrower set of situations: teams already paying for Fastly’s CDN and delivery contract, teams that specifically want Rust, Go, or stronger Wasm-based sandboxing, or teams building the kind of server-side ad infrastructure the IAB Tech Lab has standardized around Fastly’s platform. The 2026 shift away from self-serve pricing makes Fastly Compute a worse fit for side projects, early-stage startups, or anyone who wants to model a bill without picking up the phone first.
On raw performance, the honest conclusion is that there is no definitive, independently verified winner in 2025-2026 benchmark data. Each of the three third-party sources reviewed here measured something slightly different, and the spread between microsecond and multi-millisecond cold-start numbers for the same platform shows just how much methodology matters. Run your own latency test from your actual user base before trusting either vendor’s cold-start claim at face value.
Frequently asked questions
Is Cloudflare Workers cheaper than Fastly Compute?
Based on published numbers, yes: Cloudflare Workers has a transparent $5/month entry price with 10 million included requests and no egress charges. Fastly no longer publishes self-serve Compute pricing as of 2026, so a direct cost comparison requires requesting a quote from Fastly directly.
Which platform has lower cold-start latency, Cloudflare Workers or Fastly Compute?
Independent tests disagree. Some third-party benchmarks show Fastly’s Wasm modules initializing in microseconds for small functions, while others measure both platforms in the single-digit-millisecond range for full requests. No clean, standardized 2025-2026 head-to-head benchmark currently exists, so teams should run their own regional latency tests before concluding either platform is faster for their specific workload.
Can I run Rust on Cloudflare Workers?
Workers supports WebAssembly modules, so Rust code compiled to Wasm can run on Workers, but the platform’s primary developer experience and most documentation examples center on JavaScript and TypeScript. Fastly Compute treats Rust as a first-class, commonly used language with more mature tooling support for that specific workflow.
Does Fastly Compute charge for data transfer?
Fastly bundles Compute into existing delivery/bandwidth plans rather than itemizing a separate Compute-specific egress rate. Cloudflare Workers, by contrast, explicitly charges nothing for data transfer or throughput on its base plan, which Cloudflare’s pricing documentation states directly.
What is the memory limit on Cloudflare Workers?
128 MB per isolate, the same limit on both the Workers Free and Workers Paid plans, according to Cloudflare’s official platform limits documentation.
Who uses Cloudflare Workers in production?
Shopify, Discord, and Ninetailed all have published Cloudflare case studies describing production Workers deployments, covering commerce logic, edge request handling, and real-time personalization respectively.
Who uses Fastly Compute in production?
LaunchDarkly runs its Flagbearer@Edge feature-flag system on Fastly Compute, and Fastly’s customer directory lists additional deployments including IAB Tech Lab’s Trusted Server framework for server-side advertising.
Should I migrate an existing app from Fastly Compute to Cloudflare Workers?
Only if the pricing opacity or language requirements of your current setup are actively causing problems. Migration requires rewriting the request handler, remapping any companion storage dependencies, and re-benchmarking latency in your actual regions, so it is a real engineering project, not a quick swap, and should be justified by a concrete cost or capability gap rather than general preference.
