Two Cities, One Stack: Pairing VPS Locations for Failover

One server in one building is a single point of failure, however good the building is. The cheapest fix is not a bigger machine, it is a second small one somewhere else. This post is about how to choose the second city, what to keep in sync, and what a pair actually costs with our plans.

It is written for the realistic case: a small team that wants to survive a site problem with minutes of downtime rather than hours, without hiring anyone to run a cluster.

What a second location buys, and what it does not

A second site protects you from things that are true of a whole building or a whole network: a power event, a fibre cut, an exchange incident, a routing problem at an upstream. It does not protect you from a bad deploy, a dropped table or an expired certificate, because those follow you everywhere. Be clear about which problem you are solving before you spend money on it.

What a pair gives you in practice is a decision you can make in five minutes at three in the morning, because the standby already exists, already has your code on it and already has a current copy of your data.

Choosing the pair

We run virtual machines in five cities. A good pair is far enough apart to fail independently and close enough that replication is not painful. The round trips below are from our Frankfurt hub.

Pair	Separation	Why this pair
Frankfurt and Amsterdam	3 ms apart	Two hubs, two facility operators, two different internet exchanges. The default for Western European traffic, and close enough for synchronous replication if your database supports it.
Vienna and Warsaw	Both under 7 ms from the hub	Covers Central and Eastern Europe evenly. Vienna reaches Austria, Czechia, Slovakia, Hungary and Slovenia, Warsaw reaches Poland and the Baltics.
Bucharest and Frankfurt	10 ms apart	Keeps the attack prone front end in Bucharest where the scrubbing capacity is, with the fallback on the main hub.
Vienna and Frankfurt	4 ms apart	Data stays inside the EU with a different jurisdiction on each side, useful when a contract names a country.

Two rules behind those choices. First, do not pair two cities that share an upstream story, because the point is independence. Second, do not pair across a continent unless your users are there, since every millisecond of separation is paid by whichever half is remote from the other.

What it costs

A standby does not have to be the same size as the primary, and for most stacks it should not be. It needs to hold the data and be able to serve a degraded version of the service while you decide what to do.

Arrangement	Primary	Standby	Monthly total
Small site, warm standby	Core in Frankfurt, €17.00	Pulse in Amsterdam, €8.50	€25.50
Equal pair, Central Europe	Core in Vienna, €17.00	Core in Warsaw, €15.00	€32.00
Attack prone front end	Forge in Bucharest, €18.00	Pulse in Frankfurt, €9.50	€27.50

Every figure is our live monthly price including the location fee, before VAT where it applies. The per city tables for all six plans are in our price by location breakdown. Unmetered traffic on both machines matters here: the replication stream between them is not a billed transfer.

Using hourly machines for drills

The part of a failover plan everybody skips is testing it. This is where paying by the hour is genuinely useful: bring up a third machine, restore your backup onto it, point a test hostname at it, confirm the application works, delete it. A Forge is €0.0389 an hour in Frankfurt or Vienna, so a two hour drill is under nine cents. Do it once a quarter and you will find the missing step in your runbook while it is cheap to find.

Two things to remember about hourly machines. Deleting them is what stops the charges, because a powered off machine still holds its disk and its address. And anything permanently on belongs on a monthly cycle instead, since 720 hourly units cost exactly one month.

What to keep in sync

In the order that hurts most when it is missing.

1. Data. Database replication if you can, a scheduled dump and restore if you cannot. Know your acceptable data loss window and make the schedule match it rather than the other way round.
2. Configuration. The standby should be built by the same script as the primary. Two machines configured by hand diverge within a fortnight, and the divergence surfaces exactly when you fail over.
3. Secrets and certificates. Both machines need current certificates. An expired certificate on the standby is the classic failed failover.
4. Uploads and user files. Anything written by the application at runtime and not stored in the database. This is the one people forget.
5. Cron and scheduled jobs. Present on both, but active on one. Two machines sending the same invoice run is worse than none.

Traffic between our sites crosses the public internet, so put the replication and file sync inside an encrypted tunnel between the two machines rather than exposing a database port. A WireGuard link between two virtual machines takes a few minutes and is the standard answer.

How the switch happens

Keep this boring and write it down.

• DNS with a short time to live. Set 60 seconds on the records that matter well in advance. A record with a one day time to live cannot be failed over quickly no matter what you do at the moment of the incident.
• Health checks that decide. A DNS provider with health checking will move traffic for you. Without one, the switch is a manual record change, which is fine if somebody is on call and knows the procedure.
• Promote the database deliberately. Automatic promotion on a two node pair is how you end up with two machines both accepting writes. For a small stack, a human promoting the replica is safer than clever automation.
• Know how you will come back. The plan for returning to the primary is part of the plan. Usually the old primary becomes the new standby rather than being promoted straight back.

We do not sell a managed load balancer, so the routing decision lives with your DNS provider or with a proxy you run. Our guide to running a reverse proxy covers the proxy side, and the piece on what the uptime nines actually cost puts the numbers around how much redundancy is worth buying.

A sensible first step

If you have one server today, the useful first move is not a second web server. It is a second machine in another city holding a restorable copy of your data, with the build script that recreates the application. That is a Pulse or a Core for under €10 a month, and it converts a site incident from an unknown outage into a known procedure.

Plans and cities are on the VPS page, and the locations page lists what each site is good at and which site we would pair it with. If you tell us what you run today, we will tell you which pair we would build for it.