Cloudflare Workers and Pages are cheapest for bandwidth-heavy sites, egress is effectively free and R2 sits next to it. Fly and Railway are the best conventional container hosts, Render is the simplest managed option, and self-hosting with Coolify on a VPS is the floor if you'll own the operations.
Editorial judgement last reviewedAlmost everyone arriving at this question is looking at a bill. Premium platforms charge premium rates for data transfer, and a site serving significant media discovers that the hosting is cheap and the bandwidth is not.
Before changing hosts, check where the bytes are going. If most of your egress is images, video or downloads, moving those to object storage with free egress behind a CDN will save more than any platform migration, and it's a day of work rather than a month. Our S3-compatible storage comparison covers that side.
If the traffic really is your application's responses, the platform choice matters, and the differences are large. Everything below is drawn from our Vercel
alternatives hub, which compares thirteen platforms on bandwidth pricing, build minutes, runtime model, regions and seat costs.
We ranked on total cost for a bandwidth-heavy application, then on what you give up to get it.
Bandwidth pricing, including what's bundled and what overage costs. This is the line item driving the question.
Runtime constraints. The cheapest options run a non-Node runtime or a plain container. Whether your dependencies survive that is the first thing to check.
Operational burden. A VPS is cheapest and you own uptime, deploys, TLS and the 3am page. That's a real job with a real cost.
Regions, because serving Australian users from Virginia is a latency problem no pricing model fixes.
Seat costs, which nobody budgets for. A team of fifteen where four people deploy is paying for eleven dashboard viewers on a per-seat platform.
Bandwidth is effectively free, which ends most versions of this argument immediately. Workers run at hundreds of edge locations including several in Australia, requests are billed per million at rates that look like a rounding error next to premium platforms, and R2
sits next door with no egress fees at all.
For a bandwidth-heavy site this is the cheapest credible option by a wide margin, and it's not a compromise on performance, the edge network is genuinely fast and the cold starts are effectively nil.
The constraint is the runtime. Workers is a V8 isolate environment rather than Node, so dependencies that reach for Node APIs, native modules or long-running processes need checking. Compatibility has improved a great deal and most modern frameworks deploy cleanly, but audit your dependency tree before committing.
Long-running background work is also a poor fit; use Queues or Durable Objects rather than trying to hold a process open.
Runs actual containers close to users, in more than thirty regions including Sydney. If your dependencies need Node, a native module, a persistent process or a filesystem, Fly gives you that without the edge runtime's constraints, and still puts it near your users.
Bandwidth pricing is far below the premium platforms, and volumes plus a managed Postgres
option mean an entire application can live there. The scale-to-zero behaviour on machines makes low-traffic services genuinely cheap.
More configuration than a push-to-deploy platform: you're thinking about regions, machine sizes and health checks. In exchange you get real control and a Sydney presence, which matters if your users are here.
The closest thing to Vercel's ease of use with container-host economics. Push to deploy, managed databases, environment management that makes sense, and a usage-based bill that's substantially lower than a premium platform at the same traffic.
Bandwidth is priced per gigabyte at a rate well below the premium tier, and because you're running a normal container there are no runtime surprises, anything that runs in Docker runs here.
Not as cheap as Cloudflare for pure bandwidth, and not as globally distributed as Fly. It's the pragmatic middle: much cheaper than what you're leaving, much easier than what's below it.
Straightforward managed hosting for web services, static sites, background workers and cron jobs, with generous bundled bandwidth and predictable overage. If you want something that behaves like a normal PaaS and produces a bill you can forecast, Render is the least surprising choice here.
Static sites get a global CDN included, which covers a good share of the bandwidth-heavy cases without any extra thought.
Fewer regions than Fly and less raw cheapness than Cloudflare, but the operational simplicity is real. For a team that wants to stop thinking about hosting entirely at a fraction of premium pricing, it's a sensible landing spot.
Open-source self-hosted PaaS: install it on a VPS and get push-to-deploy, TLS, databases and preview environments on hardware you rent directly. A machine that costs less per month than a single seat on a premium platform will serve more traffic than most products ever see, and bandwidth on a European or Australian VPS is usually generous or unmetered.
The saving is enormous and the trade is unambiguous: you own uptime, backups, security patching, TLS renewal and the pager. That is a real job. Coolify
does the deploy tooling well, but nothing does the operations for you.
Right for teams with the appetite. Wrong for teams who'd be doing it to save a hundred dollars a month while their engineering time costs multiples of that.
The most common expensive bandwidth bill isn't the application at all, it's images, video, fonts and downloads served through the application's host at the host's rates.
The fix is boring and effective. Put static assets in object storage with free or cheap egress, Cloudflare R2 or Backblaze B2
behind a CDN, and serve them from there. Your host now serves HTML and JSON, which is a fraction of the bytes. On a media-heavy site this routinely cuts the hosting bill by most of it, and it takes a day.
Do the other obvious things while you're in there. Serve modern image formats at the size actually displayed rather than a full-resolution original scaled by CSS. Set long cache headers on immutable assets with hashed filenames. Make sure your CDN is actually caching, a misconfigured cache-control header that turns every request into an origin hit is astonishingly common and completely invisible until you check the hit rate.
Measure the split between asset bytes and application bytes before deciding anything. Half the people asking this question don't have a hosting problem; they have a caching problem.
Whatever you choose, the second migration should be cheaper than the first. That's a code decision, not a platform one.
Keep business logic in plain functions that take inputs and return outputs, with platform specifics in thin adapters at the edge. Code written against standard Request and Response objects moves between every platform on this page. Code that reaches for a provider's caching helpers, environment magic or proprietary storage bindings does not.
Prefer standard interfaces where a standard exists: S3 for object storage, Postgres for the database, plain HTTP for everything else. Every one of those has a dozen providers, which means every one of them is a price negotiation rather than a lock-in.
Watch out for the small dependencies that quietly pin you: an image optimisation endpoint, a KV store with a proprietary API, an authentication integration that assumes the platform's environment. Each is individually trivial and collectively the reason a migration takes a month instead of a week.
Finally, check regions before price. Serving Australian users from a US region adds a couple of hundred milliseconds to every uncached request, and no pricing model compensates for that.
Usually because static assets are being served through your application host at platform rates. Move images, video and downloads to object storage with free egress behind a CDN, that single change fixes most of these bills without switching hosts.
Yes, via the Workers adapters, and support has improved substantially. Audit your dependencies for Node APIs and native modules first, pin your framework version, and test the specific features you rely on before migrating anything.
Fly has a Sydney region and Cloudflare has multiple Australian edge locations, so both serve local users well. Most premium platforms serve Australia from Singapore or the US, which is a couple of hundred milliseconds you can't buy back.
