The fair question
Why not just run nginx?
Plenty of people should. nginx is superb, its configuration file is not that hard, and a single server with three sites on it does not need any of this. This page is about where the line actually is.
This is not a replacement for nginx
It drives nginx. The same nginx, built from source with more modules than the distribution
package carries. Every site becomes a server block, every pool becomes an
upstream, and you can read the generated config on screen at any time.
Nothing here stops you writing config by hand either: each site has a mode where you write the whole server block yourself, and it still goes through the same checks.
What the layer on top adds
| Job | By hand | Here |
|---|---|---|
| Knowing a backend is down | Passive only. A visitor gets the error first. | Active checks from every node, on a schedule, with the upstream rewritten. |
| Two servers agreeing | A person, a checklist, and hope. | Two phase apply. Nothing goes live unless every node accepted it. |
| A typo in the config | Reload fails, or worse, nginx does not start on both. | Tested on every node before any node uses it. The worst case is a config that refuses to save. |
| Certificates in a cluster | certbot on a timer, failing on whichever node does not own the address. | Worked out fresh at every renewal, token pushed everywhere, result replicated. |
| Rolling back | Whatever is in your version control, if you kept it. | Every applied version stored, with who and what, put back with one click. |
| Who changed what | Shell history, if anybody looks. | An audit log with the actor, the time and the source address. |
| Failing over a whole server | Nothing. DNS is somebody else's job. | DNS failover built in, handing out only healthy nodes. |
| A backend behind NAT | A firewall ticket, or a public address you did not want. | One command on that machine and it becomes a pool member. |
| Getting a WAF on | Compile ModSecurity, find the rules, work out the tuning. | Installed fleet wide from a page, per site, starting in watching mode, with learning sessions. |
| Sticky sessions | ip_hash, or writing the map blocks yourself and getting the cookie wrong. | Generated, with the two subtleties handled. |
| Somebody else running it | They have to know nginx. | They have to know how to read a form with help text on it. |
The real argument is the last row
A load balancer configured by hand in text files is a load balancer that one person understands. When that person is unavailable, everybody else is looking at a file they are afraid to touch, at the worst possible moment.
Everything else on that table is a convenience. That one is a resilience property, and it is the reason this exists.
When you should stay with hand written nginx
Do not adopt this if
- You have one server and no plan for a second. Most of what is here is about keeping two in step.
- Your config is already in version control, deployed by a tool everybody trusts, and nobody is afraid of it. You have solved the problem a different way, and it is a good way.
- You need a directive that only makes sense hand written, everywhere, and the raw config box would end up being the whole config.
- You genuinely enjoy it and nobody else needs to. That is a real reason and there is nothing wrong with it.
Trying it without committing to it
The import page reads your existing configuration and shows you exactly what it would become, and writes nothing at all. You can point it at your live config purely to see what this makes of it, and then walk away.
Even after importing, everything arrives switched off and unapplied. So the whole exercise costs one server and an afternoon, and if you do not like it you have lost the afternoon.
What free nginx already does brilliantly
Worth saying plainly, because none of it is this project's doing. TLS termination, HTTP/2 and HTTP/3, caching, compression, rate and connection limiting, the whole stream module for TCP and UDP, and a request handling model that is famously frugal. In the capability comparison, several rows score five for everybody precisely because they are the engine doing the work.
What free nginx does not have is the management layer: no interface, no active health checks, no cluster awareness, no certificate lifecycle. That is the gap, and that is all this fills.