Free and open source
A failover load balancer you can actually afford
Failover LB turns two or more nginx servers into one load balancer with failover at both layers. Broken application servers are pulled out of the pool on their own. A whole load balancer going down does not take the site with it. You drive all of it from a web page, and it costs nothing, forever.
Failover happens at two layers, and most tools only do one
When people say they want a failover load balancer they usually mean one of two different things, and it is worth being clear about which, because the answers are not the same.
Backend failover is the common one. You have three application servers, one falls over, and traffic should stop going to it. Plain nginx does a weak version of this on its own: it notices a request failed and stops trying that server for a while. The visitor who made that request still got the error. Real health checks probe every backend on a schedule, so a broken server is found before a visitor finds it.
Node failover is the one people forget until it bites. Your load balancer is also a server. If it is the only one, you have not removed a single point of failure, you have moved it and given it a nicer name. Two nodes both serve traffic, both hold the whole configuration, and either one can carry the site alone.
The test that matters
Turn off the load balancer itself, not a backend, and see whether your site is still up. That is the question a failover load balancer is supposed to answer, and it is the one most setups quietly fail.
How the failover works here
| What breaks | What happens | How long |
|---|---|---|
| One application server | Health checks fail, the server is taken out of the pool, traffic goes to the rest. | One check cycle, a few seconds |
| An application server recovers | Checks pass, it comes back, and slow start eases traffic onto it rather than dumping the full share on a cold server. | Your slow start window |
| The active node | The standby takes over the role. Both were already serving traffic, so nothing has to warm up. | Seconds |
| A whole node, from the visitor's side | DNS failover stops handing out that node's address. Visitors are steered to a node that answers. | Your DNS TTL |
| A whole building | Put a node somewhere else. DNS failover is what makes that work, because nothing else can steer traffic away from a site you cannot reach. | Your DNS TTL |
Nothing sits in the middle
Every node holds the entire configuration. There is no central controller, no shared database and no primary that everything else depends on, because that would be one more thing whose failure takes the whole fleet with it.
Changes go out in two phases. A change is offered to every node, each node checks whether the resulting nginx config is valid, and only if all of them say yes does anything go live. A typo cannot take out the fleet. The worst case is a change that refuses to save, which is a much better bad day.
What free means in a load balancer with failover
It means MIT licensed and complete. Plenty of products are free right up to the point where you want a second node, which is the exact point a failover setup begins. Here there is no paid tier, no node limit, no feature switched off until you talk to somebody, no license server and nothing that reports back. You can read the code, change it, run it at work, and never speak to anybody about it.
This exists because a non profit needed a load balancer and the commercial ones cost more than the servers they would run on. The reason it is free is that the problem was never the software being hard, it was the price of the software being absurd.
What it costs to run
Two small servers. Two virtual machines with 2 cores and 4GB each will carry a great deal of traffic. There is no per node fee, so the cost of making it properly redundant is the cost of the second machine and nothing else.
What comes with it
Failover is the name on the tin, but a load balancer that only balances is not much use on its own. What is here is what a site actually needs to go live:
Active health checks
Probe every backend on a schedule and pull the dead ones out.
Read moreActive and standby
One node takes changes, both serve traffic.
Read moreDNS failover and GSLB
Hand out the address of a node that is actually up.
Read moreLet's Encrypt certificates
Free certificates that renew themselves, in a cluster.
Read moreWeb application firewall
ModSecurity with the OWASP Core Rule Set, per site.
Read moreClustering
Every node holds the whole config. No central controller.
Read moreWhere to start
- Install on one server. It is one command, and it is safe to run twice.
- Make a pool, add your application servers, turn on health checks.
- Make a site, point it at the pool, get a certificate.
- Add the second node and join it to the first.
- Turn off the first node on purpose and check the site is still up.
Step five is the one people skip and the one that matters. A failover setup you have never tested is a guess. The two node cluster guide walks through it, and the maintenance window guide covers doing it on purpose without anybody noticing.
Questions people ask
What is a failover load balancer?
A load balancer spreads traffic over several servers. A failover load balancer also notices when one of them stops working and stops sending traffic there, without anybody being woken up. The useful ones do it at two layers: they drop a broken application server out of the pool, and they survive one of the load balancers themselves dying.
Is there a genuinely free load balancer with failover?
Yes. Failover LB is MIT licensed with no paid tier, no node count, no feature held back and nothing that phones home. The free loadbalancer failover story is the whole product rather than a trial of it. It was written for a non profit that could not afford a commercial appliance, and it is given away for the same reason.
How fast does it fail over?
A dead backend is out of rotation within one health check cycle, which you set and which defaults to a few seconds. A dead node is out of the DNS answer within the same window, but visitors also have to wait for their cached DNS record to expire, so plan on the TTL you set plus a few seconds. Sixty second TTLs are a reasonable place to start.
Do I need two servers?
For real failover, yes. One server running a load balancer is a single point of failure wearing a hat. Two small servers beat one large one for this job, and the second one is not idle: both serve traffic all the time.
Does it replace nginx?
No, it drives nginx. Every site you make becomes an nginx server block and every pool becomes an upstream, and you can read the generated config on screen before it goes live. Nothing is hidden from you and nothing stops you writing a block by hand.
Try turning a server off
Ubuntu 22.04 or newer, root access, and about twenty minutes. The installer does the rest and it is safe to run twice.