Questions people ask

Yes. MIT licensed, no per node fee, no license key, no sales call. Use it commercially, fork it, change it, ship it inside something else. The cost is not zero, it has just moved: you carry the build, you carry the upgrades, and when it breaks the person fixing it is you.

Tim Rice, for hackrange.com, a non profit that needed a proper edge and could not spend four figures a year per server on one. The whole story is on the why page.

It runs a real non profit's infrastructure, and the load test numbers on this site came from that fleet. That is not the same as saying it is right for you. If your requirements include a support contract or a third party security audit, those requirements are not met and no amount of description changes that.

There is nobody to call at three in the morning. That is the first row on the comparison page and the one we lose worst. There is also no third party security audit. Everything else is on the comparison page, including the eighteen rows that go against us.

The license is MIT, which cannot be taken back for the code that has already been released. Whatever happens to the project, the version you have stays yours.

Yes. MIT places no restriction on commercial use. You do not owe anybody anything and you do not have to tell anybody.

One or two servers running Ubuntu 22.04 or newer, with internet access and root. A domain name you control, so you can get certificates. That is the whole list.

Smaller than most people expect. Four processors and four gigabytes handles up to about 2,000 requests a second comfortably. The thing that runs out first is network bandwidth, not processor. The sizing guide has real numbers.

It is written for Ubuntu and tested on the long term support releases. Debian will very likely work. Anything else is not something this promises. There is a section on the why page explaining the choice, including the part of it that is a grudge about CentOS.

Yes. You get the GUI, the certificates, the WAF, health checks and everything else except failover. Adding a second node later is a token and one command.

The manager runs in Docker, on the host, beside the nginx it drives. It is not designed to be an ingress controller and it does not try to be one. If you are on Kubernetes, use an ingress controller.

It replaces the nginx binary with one built from source, which is the point. Do not let apt install the distribution nginx package afterwards, because that drops a stock binary on top and you lose every module.

No, it drives nginx. Every site becomes a server block and every pool becomes an upstream, and you can read the generated config on screen at any time. Each site also has a mode where you write the whole server block yourself.

Yes. The manager probes every backend on a schedule from every node and rewrites the upstream with failed members marked down. That is the paid version's headline feature, done from outside the process.

That is one of the main reasons it exists. At every renewal it works out which node currently owns the public address, pushes the challenge token to every node before validation starts, and copies the result everywhere.

ModSecurity with the OWASP Core Rule Set, installed fleet wide, per site, starting in watching mode with learning sessions to tune it. It is the real thing.

Yes, the build includes the module. Turn it on per site and make sure UDP 443 is open, because QUIC does not use TCP.

Yes. TCP and UDP services with their own pools, health checks and balancing methods. Databases, mail servers, DNS resolvers, game servers.

It protects against traffic captured today being decrypted once quantum computers exist. It matters for anything with a long secrecy lifetime and matters much less for something that is public anyway. It is on by default here and costs you nothing either way.

You press Apply. The whole config is built from the database, staged on every node, tested with each node's own nginx binary, and only then swapped in. If any node refuses, nothing changes anywhere.

Almost certainly nothing, because the config is tested before any node uses it. If a change is valid but wrong, every applied version is kept and putting an earlier one back is one click.

No. An nginx reload is graceful: old workers finish what they have while new ones take the new connections. The exception is very long lived connections such as WebSockets, which keep old workers around until they close.

No. Everything the GUI does is available through the JSON API, with the same roles and the same audit trail. And each site can be driven by hand written config if you prefer.

Git pull and run the installer with the upgrade option, on every node, minutes apart rather than days. It does not touch your configuration or your settings file, and nginx keeps running throughout.

The other one promotes itself and carries on. What that does not fix is visitors already pointed at the dead machine, which is what DNS failover is for.

No. It runs unprivileged with a read only filesystem and can ask a small root agent to do one of a fixed list of jobs. There is no verb that takes a command, and adding one would defeat the entire design.

It should not be exposed. The allowlist is checked before the login page renders, so a stolen password from the wrong network gets nothing, and that is a much better position than relying on the login page.

No third party 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 this project is not going to pretend it is.

For local accounts, yes. If you use single sign on instead, the provider decides what a second factor looks like.

Encrypted with a key in each node's own settings file. That is why every node needs its own file and why copying one between machines is a mistake the installer refuses.

Money, mostly, and the fact that it comes with a browser interface, a WAF and DNS failover in the box rather than as separate products. Use Plus if you need packaged video streaming, NTLM pinning, MQTT filtering, a request queue, or somebody to call.

If you are already on nginx and want to keep the config you have, if you want certificates handled end to end across a cluster, or if you have backends with no public address. HAProxy community edition is excellent and free, and if that suits you better this project is not trying to argue.

For one server with three sites, probably not. The argument gets stronger the moment you have two servers that have to agree, certificates that have to renew across them, and more than one person who might need to change something.

Yes. The import page reads your current configuration and shows you exactly what it would become, and writes nothing at all. Even after importing, everything arrives switched off.