Every few months a ticket comes in that starts with "our main server went down and nothing failed over." Usually there was no failover — just one VPS and a hope. A proper multi-region failover VPS setup doesn't need a service mesh or a six-figure cloud bill; for most small teams it needs two VPS instances in different locations, a health-check script, and a plan for what happens to DNS or IP routing when one of them stops answering. This is the version we'd actually build for ourselves — no load balancer, no orchestration platform, just the parts that matter.
What a Multi-Region Failover VPS Setup Actually Means
Strip away the marketing language and multi-region failover is one thing: traffic finds a working server even when the one it was pointed at is down. At small scale, that's an active-passive failover between two servers — one primary, one standby, in different physical locations so a single datacenter incident, upstream carrier issue, or power event doesn't take out both at once. You're not distributing load across regions for performance (that's a load balancing problem, and a different build). You're buying yourself a second place for traffic to land when the first one goes dark.
Active-Passive Failover With Two Servers: The Basic Pattern
The pattern is simple by design, which is exactly why it holds up under pressure at 3am:
- Primary VPS — runs the live application, database, whatever serves traffic normally.
- Standby VPS — in a different location, kept in sync (via replication, rsync, or periodic snapshots depending on how fresh the data needs to be), idle until called on.
- Health checker — a small script, running independently of both servers, that polls the primary on an interval.
- Failover trigger — DNS record update or IP reassignment that redirects traffic to the standby once the primary fails enough consecutive checks.
The independence of the health checker matters more than anything else on this list. If it runs on the primary server, it dies with the primary and never triggers. Run it somewhere else entirely — a third small VPS, a scheduled job on your standby, or a monitoring service that can hit an API on failure.
Location choice matters too: the exercise is pointless if both instances sit in the same building on the same upstream. Aim for genuine separation — different city, different power grid, ideally different upstream providers. Size the standby for your actual workload, not a cut-down version; a standby that can't carry production traffic isn't a real failover target.
The Health-Check Script (DNS/IP Failover)
Here's the skeleton we'd start from. It's deliberately boring — a cron job, a curl request, a threshold, and an action:
- Check interval: every 30-60 seconds is typical; tighter intervals catch failures faster but increase false-positive risk from transient blips.
- Failure threshold: require 3-5 consecutive failed checks before triggering failover. One bad ping is noise, not an outage.
- The check itself: hit a real endpoint, not just a ping — an HTTP health route that confirms the application (not just the network stack) is responding.
- The action: update a DNS A record via your DNS provider's API to point at the standby's IP, or — if you control the IP block — reassign the address directly.
- Failback: decide up front whether recovery is automatic or manual. Automatic failback sounds appealing until the primary comes back up flapping and you bounce traffic back and forth. Most teams are better off failing back manually after confirming the primary is actually stable.
A basic version is a five-line bash script on a cron timer: curl the health endpoint, count failures in a state file, call your DNS API once the threshold is crossed, log everything. It's not elegant, but it's the same core logic every "smart" failover product runs — just wrapped in a UI.
VPS Failover Without a Load Balancer — Where This Breaks Down
DNS-based failover has a well-known limitation: DNS caching. Even with a low TTL, some resolvers hang onto the old record longer than you'd like, so failover isn't instant — expect anywhere from under a minute to several minutes depending on TTL and who's asking. For most small teams and internal tools, that's an acceptable trade-off for the complexity it avoids.
Where this pattern genuinely breaks down:
- Sub-second failover requirements — DNS propagation delay is a hard floor you can't engineer around at this layer.
- Stateful sessions that can't tolerate a cold standby — if failover means users get logged out or lose in-progress work, you need active replication design work beyond what a health-check script covers.
- Compliance or SLA commitments that require route-level guarantees — DNS-based failover is best-effort, not a contractual uptime mechanism.
When BYOIP and Your Own AS Become Worth It
The next step up from DNS failover is IP-level failover: instead of waiting for a DNS record to propagate, you announce the same IP block from wherever it's currently active and let routing (BGP) handle the switch. This is faster and more deterministic, but it requires you to control the IP space being announced — which means BGP and BYOIP.
This isn't a step to take casually: BYOIP setups typically require a minimum block size, RPKI/ROA configuration, and LOA/IRR paperwork before anyone will route your prefix. It's the right move once uptime requirements tighten past what DNS failover can deliver — but it's overkill for a side project. Our BYOIP page covers what's actually required, including minimum block sizes and the RPKI/IRR process. Teams that need dedicated capacity behind that setup, rather than shared VPS resources, should also look at dedicated servers with BGP available on request — that combination is usually the real endpoint once "multi-region failover" starts meaning something more serious than two VPS instances and a cron job.
How Noded Can Help
We run VPS across multiple EU and US locations on our own network — AS60982, not a reseller's — so picking a primary and standby location means picking real physical and network separation, not two labels on the same infrastructure. Every VPS ships with a full 1 Gbps unmetered symmetric connection and both IPv4 and IPv6 out of the box, which covers everything the health-check-and-DNS pattern in this post needs. Root SSH access means you're free to run the cron job, the health checker, and the failover script exactly as described, with no platform in the way. And when a setup outgrows DNS-based failover, BGP and BYOIP are available on request against our own AS — so the next step is a conversation with the same provider, not a migration to a new one. Our VPS hosting page has the location and sizing options to get your primary and standby running today.
FAQ
Do I need a load balancer for basic multi-region failover?
No. VPS failover without a load balancer is entirely workable for active-passive setups — a health-check script and DNS or IP failover cover most small-team needs. Load balancers solve a distribution problem (spreading live traffic across servers); failover solves an availability problem (finding a working server after one fails). They're related but not the same build.
How fast is DNS-based failover compared to BGP/IP-based failover?
DNS failover typically takes anywhere from under a minute to several minutes depending on TTL and resolver caching behavior. BGP-based failover, once your own IP space and AS routing are in place, is considerably faster because you're rerouting the same address rather than waiting for clients to look up a new one — though it's still route propagation across networks, not instantaneous. The trade-off is that BGP/BYOIP requires meeting minimum block size requirements and completing RPKI/IRR setup first.
Should my standby VPS be the same size as my primary?
If the standby genuinely needs to carry production traffic during an outage, size it the same as the primary. Undersizing "just to save cost" defeats the purpose — a standby that can't handle real load isn't a failover target, it's a false sense of security.
Can I automate failback to the primary once it recovers?
You can, but most teams are better off doing it manually. A primary that comes back online and then flaps (goes up and down repeatedly) can cause automatic failback to bounce traffic back and forth, which is often worse than staying on the standby a little longer while you confirm stability.
Do both VPS instances need to be in the same country?
No — the point of multi-region failover is deliberate separation. Choosing different locations, ideally across different power grids and upstream providers, is what protects you from a single datacenter or regional event taking down both instances at once.