Fly.io vs Cloudflare Workers
This comparison only makes sense for part of what Fly does. Workers are built for short, stateless request handling; Fly runs full, long-lived VMs. Putting them side by side only helps if you're honest about which one your app actually needs.
Pick Cloudflare Workers if you're writing edge functions, API routes or request/response logic that finishes in seconds. Stay on Fly (or look at Render or Railway instead) if you're running a full backend, a long process or anything that needs a persistent filesystem.
Side by side
Fly.io vs Cloudflare Workers at a glance
| Fly.io | Cloudflare Workers | |
|---|---|---|
| Runtime model | Firecracker microVM | V8 isolate, not a VM or container |
| Free plan | None for new signups since Oct 2024 | 100,000 requests/day |
| Entry paid tier | ~$2/mo smallest Machine | $5/mo for 10M requests + 30M CPU-ms |
| Max execution time | Unlimited, long-running by design | 5 minutes, even on paid |
| Persistent filesystem | Yes, attached volumes | No |
| Cold start | None, always-on by default | Near-instant, no VM to boot |
| Best for | Full, long-running backend services | Edge functions and API logic |
Sources: Fly.io pricing · Cloudflare Workers pricing. Compiled July 2026.
Where Cloudflare Workers wins
Near-zero cold start, at global scale
Workers run in V8 isolates, the same lightweight execution model Chrome uses for JavaScript, so a single process can host thousands of them without booting an OS per request. For request-scoped logic, latency is genuinely lower than anything running behind a boot sequence.
The free tier is a real free tier
100,000 requests a day at no cost, resetting daily, is enough to run a lot of small API routes or edge logic indefinitely without a card on file, unlike Fly's current no-free-tier-for-new-signups reality.
Where Fly.io still wins
Workers cap execution at 5 minutes even on the paid plan and have no persistent filesystem. That rules out most of what people actually run on Fly: long processes, background workers, anything stateful, or a full backend attached to a database over more than a request cycle. This isn't a weakness of Workers, it's a different product category.
Cloudflare does sell a separate Containers product for exactly this gap, generally available since April 2026, and it's the fairer comparison if you specifically want Cloudflare's network for a full-VM-style workload. Its pricing wasn't verifiable clearly enough at the time of writing to state with confidence here, so check Cloudflare's own Containers pricing page directly before committing.
Migrating parts of a Fly.io app to Workers
This is usually a partial migration, not a full one:
1. Split the workload. Identify which routes are genuinely short-lived request/response logic versus which need a persistent process or filesystem.
2. Move the stateless parts. API routes, redirects, auth checks and similar logic can move to a Worker with a rewrite for the Workers runtime, since it isn't Node.js underneath.
3. Keep the rest where it belongs. Long-running services and anything touching a persistent volume stays on Fly, Render or Railway; don't force it into a 5-minute execution window.
4. What does not move. Any dependency on Node-specific APIs or a local filesystem needs a rewrite, not a copy-paste, since Workers isn't a Node.js environment.
Common questions
FAQ: Fly.io vs Cloudflare Workers
Can Cloudflare Workers fully replace Fly.io?
Not for most Fly workloads. Workers run in V8 isolates with a 5-minute execution cap and no persistent filesystem, built for short request and response logic. Fly runs full, long-lived VMs. Cloudflare's separate Containers product, generally available since April 2026, is the closer match to Fly's category.
Is Cloudflare Workers cheaper than Fly.io?
For the workloads Workers is actually built for, yes: 100,000 free requests a day, then $5/mo for 10 million. But that's not a fair comparison against Fly's VM pricing, since the two products aren't running the same kind of workload.
Why doesn't Cloudflare Workers have Fly's cold-start problem?
Workers don't boot a VM per request. They run in V8 isolates, the same lightweight process model that powers Chrome's JavaScript engine, so there's no OS or container to spin up. Fly's Machines don't have this problem either when left always-on; the tradeoff is that Fly's approach bills for that always-on time.