A client asks a version of the same question every few months, usually right after a customer in the US or Australia complains that the site feels sluggish: ‘should we go multi-region?’ It’s a reasonable question and almost never the right one to answer first. The right first question is where their users actually are, and whether the business can tell the difference between 80ms and 280ms. Most of the time it can’t, and the conversation ends there. Sometimes it can, and then the real question starts: pay a managed platform to multiply your bill per region, or take on the ops work of running your own infrastructure in more than one place. Both are legitimate answers. Neither is free.
What Single-Region Actually Costs You
A Next.js app deployed to one region – one Vercel region, one VPS, doesn’t matter – serves every request from that single physical location. A user near it gets a fast response. A user on the other side of the planet pays for the distance: every request round-trips through however many hundred milliseconds of speed-of-light-plus-routing delay that separate them from your server, on top of whatever your app itself takes to respond. As a rough order of magnitude, cross-continental round trips (say, Europe to US West, or Europe to Australia) commonly add somewhere in the 100–300ms range before your code runs at all. That’s not a number I measured for any specific deployment – it’s the general physics of distance and network hops, and it’s why CDNs exist for static assets in the first place. For a page that fires off several sequential API calls or waits on server-side rendering, that per-request tax compounds.
The other cost of single-region isn’t latency, it’s fragility. One region means one point of failure. If that region’s data center, network, or your host’s account there has a bad day, the whole app goes down for everyone, not just for people near it. For most businesses that’s an acceptable, rare risk they’ve implicitly accepted by hosting anywhere at all. For a small number, an hour of downtime has a real, calculable cost, and that changes the answer.
When Single-Region Is the Right Answer
If your audience is regional – a Finnish business serving Finnish customers, an internal tool used by one company’s staff in one office, a SaaS product still validating whether anyone wants it before it has users outside its founder’s own time zone – multi-region hosting solves a problem you don’t have. The added complexity buys you milliseconds nobody will notice and infrastructure nobody on the team is set up to operate. I’ve watched early-stage teams spend a sprint on cross-region deployment before they’d spent a week finding out whether the product itself works. That’s infrastructure investment ahead of product-market fit, and it’s close to the most common form of premature optimization I see in this kind of work.
Even for a genuinely international audience, single-region with a CDN in front of it covers more ground than people assume. Static assets, images, and anything cacheable already get served from edge locations near the user regardless of where your app server lives – that’s what a CDN is for, and it’s a much smaller lift than duplicating the app itself. What a CDN can’t fix is the latency of a dynamic, server-rendered request or an API call that has to reach your one origin server no matter where the visitor is. That’s the actual thing multi-region hosting buys you: faster dynamic responses and redundancy against a single region’s outage, nothing else. If your app is mostly static pages with light dynamic bits, you’re paying for a problem the CDN mostly already solved.
The honest litmus test: can you name the customer segment that’s affected, and can you say what it costs the business when they wait an extra 150ms or when the one region goes down for an hour? If the answer is ‘I’m not sure’ or ‘it would be annoying but nothing breaks,’ you don’t need multi-region yet. Build the case with real numbers before you build the infrastructure.
What Managed Platforms Charge You Per Region
If the case is real, the first thing to understand is that a platform like Vercel doesn’t give you multi-region for free just because you flip a setting. The billing mechanism, generally, multiplies with region count: serverless/edge function execution is billed per invocation, and running the same function in three regions instead of one means three times the invocations for the same traffic, not the same total split three ways. Bandwidth is typically metered per region too. I’m not going to quote a specific current dollar figure here – pricing pages change and I haven’t verified today’s numbers against a real multi-region Vercel bill – but the mechanism itself is well documented and worth understanding before you commit: you’re not paying more to reach more users, you’re paying a multiplier on the same users because the same work now runs in more places.
Pikkuna, an e-commerce platform I built that ships to 32 countries, runs on Vercel across three regions – Frankfurt, Stockholm, and Cleveland, per the project’s own numbers. The specific routing and cost mechanics of that setup are Vercel’s, not something I’ve documented in code, and I don’t have data on why three was picked or how it performs against a different count, so I won’t infer either. What I will say as my own general heuristic, not a conclusion drawn from Pikkuna: multi-region rarely needs to mean many regions. For most businesses that actually need it, two or three, chosen to bracket where the customers are, is usually enough – not a global mesh.
The convenience you’re buying at that price is real: automatic geo-routing sends each user to the nearest region without you writing any routing logic, and the platform’s operators – not you – own keeping every region’s build in sync, healthy, and patched.
What Self-Hosting 2–3 Regions Actually Costs
The instinct once you’ve seen a per-region multiplier on a platform bill is to reach for self-hosting instead. The vatnode.dev API runs on a €6/month Vultr instance, one region, one box – but that box runs a lightweight Hono API, a BullMQ worker, and Redis, not a Next.js SSR app, and it’s not a fair stand-in for what a Next.js app needs. This site’s own Next.js deployment runs under a 1 GiB memory ceiling on Coolify – tight enough that CV PDF generation was moved out of runtime and into the build step specifically to stay under it. A self-hosted Next.js SSR box needs real headroom in a way a small API worker doesn’t. So multiplying €6/month by two or three regions to get a tidy €12–18/month figure would understate the real cost; budget for a Next.js-sized VPS per region, not an API-sized one. The raw compute line is still the cheapest part of this decision either way. It’s also the easy part to see. The ops cost below is the harder one.
Running your own app in N regions instead of one region means you now own, in full, everything the managed platform used to do for you:
- Keeping deploys in sync. A release has to land on every region’s server, in order, without one region silently running an older build for an hour because a deploy step failed on it and nobody noticed. That’s either a deploy script written to fan out to N hosts and verify each one, or N manual deploys, and the second option is the one where a self-hosted multi-region setup is most likely to fail quietly – the cause is a deploy someone forgot to run on the second box, not the architecture.
- Secrets and environment management across N hosts. Every API key, database credential, and signing secret now needs to exist correctly on every server, and stay in sync when it rotates. One region’s stale environment variable file is the kind of bug that’s invisible until the region that has it handles a request that needs the new value.
- Monitoring N hosts instead of one. Structured logging and error tracking that made sense as ‘check the one dashboard’ now needs to distinguish which region a request or error came from, and someone has to actually watch all N dashboards, not just the one they’re used to checking.
- Database strategy. This is the part that’s easy to underestimate. An app in three regions still needs its data to be consistent somewhere. A single-writer database with regional read replicas keeps writes simple but means every write from a far-away region pays the same cross-region latency the whole exercise was meant to avoid. A multi-writer or regional-shard setup avoids that but is real distributed-systems work – conflict resolution, replication lag, and a much larger set of failure modes than a single Postgres instance ever had. There is no version of this that’s ‘just point the app at three databases’ and walk away.
- Routing users to the nearest region. A managed platform’s edge network does this invisibly. Self-hosted, it means GeoDNS or an anycast setup in front of your regions, configured and maintained by you, plus a plan for what happens when the geo-routing layer sends a user to a region that’s currently down – which is exactly the failure mode multi-region was supposed to protect against in the first place.
None of that is a reason not to self-host multi-region. It’s a reason to price it honestly. The monthly VPS bill for three boxes is the smallest number in this decision and the easiest one to put in a proposal, which is exactly why proposals get the total wrong.
The Trade-Off, Stated Plainly
Neither path is the objectively correct one. A managed platform’s per-region pricing buys you geo-routing, region health, and deploy consistency that someone else operates and gets paged for, not you. Self-hosting trades that convenience for a lower recurring infrastructure bill and a real, ongoing commitment of engineering time to keep N regions in sync, monitored, and correctly routed – work that never shows up on an invoice, only in someone’s calendar every time there’s a deploy, an incident, or a database question a single-region setup never had to ask.
The businesses that get this right are the ones that make the choice deliberately, with the actual ops capacity to operate whichever side they pick, instead of defaulting to ‘self-hosted is always cheaper’ or ‘managed is always safer.’ Both defaults are wrong often enough to be worth checking against the specific case in front of you: who’s on call, how often you deploy, how much a bad region-sync bug actually costs versus how much the platform’s multiplier costs, and whether the audience genuinely needs multi-region at all – the question this article opened with, and the one worth answering again before signing up for either bill.
That’s the decision worth working through deliberately: an honest accounting of what each path actually costs, before either one gets built.
Not sure whether the ops burden of running your own regions would outweigh the platform’s markup, or the other way round? Get in touch – I’m available for technical consultation on infrastructure and deployment decisions like this one.
Further reading:
- Self-Hosting Node.js API: Caddy, Docker Compose, VPS – the single-region self-hosted pattern this article’s cost anchor is drawn from
- next/image Optimization on a Self-Hosted VPS – another self-hosted-vs-managed trade-off, at the image pipeline level instead of the region level
- Structured Logging with Pino in Next.js – the monitoring foundation you need before you’re watching N regions instead of one
- Pikkuna – E-commerce for Vinyl Curtains & PVC Products – the three-region Vercel deployment referenced above
