I needed this for a non profit, so I built it. Then I gave it away.

The thing that started it

I own and run hackrange.com, a non profit. Over time its web infrastructure grew the way these things do: a service here, an application there, a couple of machines that somebody set up years ago and that everybody is slightly afraid of. Each one had its own certificate, its own idea of TLS, its own firewall rules, and its own way of being wrong.

That is fine right up until it is not. The moment you have more than a handful of public hostnames, you need one place that owns the edge. Not because it is tidier, though it is, but because every single thing you want to do well at the edge is a thing you do not want to do six times.

What it actually had to do

I wrote the list down before I wrote any code, and it has not changed much.

Centralize a large web estate

One place that knows about every public hostname, which pool serves it, and what the rules are. Adding a new service should be a form, not an afternoon and a config file nobody else can read. Moving a service between backends should not involve touching the machine it used to be on.

Offload TLS, and never think about renewal again

Terminating TLS at the edge means the backends do not each need a certificate, and it means one place to fix when a protocol version is deprecated. But the real prize is renewal.

Certificates fail on a schedule, quietly, and always at the worst time. Free automated certificates solve that on one server. On two servers they do not, because only the machine that currently owns the public address can answer the challenge, and which one that is changes when you fail over. Every setup I looked at either ignored that or papered over it, and every one of them would eventually produce a certificate that stopped renewing and nobody noticed for two months.

So the certificate handling here works out which node can answer at every renewal, pushes the challenge token to every node before validation starts, and copies the result everywhere. That single problem is a good chunk of the reason this project exists at all.

Real protection in front of the applications

Some of what a non profit runs was not written with the public internet in mind. Volunteer projects, old tools that do a useful job, things nobody has budget to rewrite. Putting a real web application firewall in front of that is the single highest value thing you can do for it.

Not a handful of regular expressions with a marketing name. ModSecurity with the OWASP Core Rule Set, per site, starting in watching mode so the first thing it does is tell you what it would have refused rather than refusing it.

Crypto that will still be worth something in ten years

Harvest now, decrypt later is the reason post quantum key exchange matters before anybody has a quantum computer. Traffic captured today gets decrypted whenever one arrives. For anything with a long secrecy lifetime, that is a problem you have to fix in advance or not at all.

Because this builds its own nginx against OpenSSL 3.5, ML-KEM is there, and the shipped TLS settings offer X25519MLKEM768 first with the classic curves behind it. A site gets it without anybody knowing to ask.

Certificates from paid authorities too

Not everything can use a free certificate. Sometimes a policy names a supplier, or an organization has an agreement already. Those suppliers mostly speak ACME now, so registering one and having it issue and renew automatically is the same job with different credentials. There was no reason to support only the free case.

Survive a server dying

Two load balancers, both serving, one taking changes. And, because two machines in different places cannot share a floating address, DNS failover as well, so a whole building going dark moves visitors rather than losing them.

The part that is about money

Everything on that list is available commercially and has been for years. It is good software and the people who make it deserve to be paid.

These are not quotes. None of the three publish a rate card you can just read, so the numbers come from reseller listings and price trackers gathered in August 2026. Treat them as the right order of magnitude and nothing finer. There is a longer version of this with the sources.

Now do the arithmetic for two load balancers with a firewall. That is a real number, every year, forever. For a lot of organizations it is more than the entire hosting budget. It was more than mine.

So I built it on free nginx

Free nginx is a superb piece of software. What it does not have is the management layer: no web interface, no active health checks, no cluster awareness, no certificate lifecycle. Those are exactly the things that are hard to live without and, it turns out, are all doable from outside the nginx process.

Active health checks become the manager probing every backend on a timer and rewriting the upstream. Sticky sessions become two generated map blocks and a consistent hash. Slow start becomes a weight that ramps. None of it is as elegant as doing it inside the process, and all of it works, and the comparison page is honest about where the seams are.

Why it is driven from a web page

Because the thing I actually needed was for this not to depend on me.

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. A screen with help text next to every setting, that refuses to save something nginx would reject, and that shows you what your choices produced, is a load balancer that more than one person can run.

That is also why every setting has a question mark next to it, why the help says what a setting does and gives an example, and why settings for modules your build does not have are simply not shown. A screen that offers you something that cannot work is worse than no screen.

Why it is Ubuntu only, and not Red Hat

I should be honest about this one before I make the sensible arguments: a good part of it is that I am still annoyed about CentOS, and I have not really got over it.

CentOS Linux 8 came out in 2019 with a published end of life in 2029. Ten years. People planned around that date, because that is what a published support window is for. You put it in a migration plan, you put it in a purchase decision, you put it in the compliance paperwork and you move on to the next problem.

In December 2020 that date moved to the end of 2021. Not a slip of a few months. Eight years early, announced at the point where a lot of organizations had just finished moving onto it. Everybody who had trusted the published date was suddenly holding an unplanned migration they had to pay for and had not budgeted.

Then in June 2023 the source stopped being published the way it had been, and downstream rebuilds got noticeably harder to keep going. The message I took from those two events together is that a support commitment was only as solid as the quarter it was made in.

That is the grudge. Here are the reasons that would still hold if I did not have one:

• Nothing to register. Ubuntu installs and updates with no account, no entitlement and no subscription manager. The free Red Hat developer subscription is genuinely useful, but it is still an account, a login and a system count. This is a tool for people who could not get a purchase order signed. Asking them to sign up for a vendor account before they can patch is the wrong first step.
• One target instead of a family. Saying it supports Red Hat really means testing RHEL, Rocky, Alma and Stream, which are close today and drift apart over time. One person cannot honestly test four moving targets. One person can test two Ubuntu long term support releases, and that is what happens.
• Newer libraries underneath. nginx here is built from source against a current OpenSSL, which is what makes post quantum key exchange possible at all. A newer base means fewer fights with the system copies of things while doing it.
• Docker is a first class citizen. This ships as containers. Red Hat reasonably prefers podman, and Docker on RHEL is a slightly awkward path that I would then have to support forever.
• AppArmor rather than SELinux. A small root agent that writes config files and reloads a service is exactly the shape SELinux is strictest about, and getting that policy right and keeping it right is real, ongoing work. AppArmor gets to the same place here for a fraction of the effort. That is partly an admission about my time, and it is an honest one.
• A cadence you can plan around. A long term support release every two years in April, supported for five. You know the dates years ahead, which is the entire thing I wanted in the first place.

What I am not claiming is that Ubuntu is a better operating system than RHEL. It is not, across the board. RHEL has longer support, deeper certification and a support contract behind it, and if your compliance regime names Red Hat then that settles the argument and you should not be taking platform advice from me. It will very likely run on Rocky or Alma, and the installer will try and tell you plainly that you are outside what is promised. Probably runs is not the same as supported, and I am not going to blur the two.

Why I am giving it away

Because I know exactly how many people are in the position I was in.

A charity. A school. A community project. A small team inside a bigger organization that cannot get a purchase order signed. A hobby project that got popular and now has real users and no revenue. All of them are running something on the public internet, all of them would benefit enormously from a proper edge, and none of them are going to spend four figures a year per server on one.

The choice those people face today is between a load balancer they can afford and a load balancer they can actually manage. That is a bad choice and it does not need to exist. Free nginx is right there. What was missing was the layer on top, and now there is one.

It is MIT licensed. Use it commercially, fork it, change it, ship it inside something else. I would rather it was useful than that it was mine.

What I want to be straight about

There are other gaps. Packaged video streaming needs modules only the paid nginx has. NTLM connection pinning cannot be faked from outside the process. There is no request queue. The live monitoring is a few seconds behind rather than instant. None of that is hidden: it is on the comparison page, with the reasoning, and eighteen of those thirty nine rows go against us.

There has also been no third party security audit. The design is written down in detail on the security page so you can judge it, and the source is deliberately small enough to read. That is not the same as an audit and I am not going to pretend it is.

What it actually runs

hackrange.com runs on it. That is where the screenshots on this site come from: a live fleet, captured against real nodes, with real certificates and real backends. The hostnames in those pictures were changed to placeholders first, since publishing a list of somebody's origin servers helps nobody. The load test numbers on the home page came from that fleet too, over a continuous hour, and the figures published are what was measured rather than what was hoped for.

That is not a claim that it is right for you. It is a claim that somebody depends on it, which is a different thing from a demo.