What is NGINX?
NGINX is an open-source web server, created by Igor Sysoev and now maintained by F5. Calling it a web server undersells it: in most deployments it is doing three or four different jobs at once, and knowing which one you need is the whole of the decision.
The four jobs
Serving static files. HTML, images, stylesheets, JavaScript, straight from disk. It is very good at this and uses very little memory doing it.
Reverse proxy. Requests arrive at NGINX and it passes them to an application behind it. The application is not exposed to the internet, does not have to handle TLS, and can be restarted without dropping connections at the edge.
Load balancer. The same, spread over several instances, with health checks so a failed one stops receiving traffic.
HTTP cache. Keeping responses so the application does not regenerate them. Less configurable than a dedicated cache, and often enough.
Most real deployments use it as all four, which is why "what is NGINX" gets confusing answers. It is one process doing whichever of these you configured.
Why it displaced what came before
The architectural difference is worth one paragraph because it explains the reputation. Older servers handled each connection with a process or thread, so a thousand simultaneous connections meant a thousand of those, most of them idle and all of them consuming memory.
NGINX is event-driven: a small number of worker processes handle many connections each, doing work only when a connection actually has something to say. Idle connections cost almost nothing. That is why it holds large numbers of concurrent connections in modest memory, and why it became the default in front of applications that could not.
Open source, NGINX Plus, and NGINX One
This is where most confusion sits, and it is a purchasing question rather than a technical one.
NGINX open source is the software described above. It is free, it is what almost everyone runs, and it is entirely sufficient for the large majority of deployments.
NGINX Plus is F5's commercial version, adding capabilities such as advanced load balancing behavior, session persistence, richer monitoring and an API for reconfiguration without a reload, plus vendor support.
NGINX One is F5's newer packaging around the commercial offering.
What Plus adds, in the terms F5 uses for it, is advanced traffic control, security and observability on top of open source NGINX. Two capabilities account for most of the reasons organizations actually buy it.
Authentication at the edge, via JWT validation. NGINX Plus can validate a JSON Web Token before the request reaches your application: it checks the signature, the expiry and whatever claims you require, and rejects or redirects anything that fails. Signed, encrypted and nested tokens are all supported.
The practical shape is the one people want: a request arriving without a valid token, or with an expired one, is sent to the login page by the proxy rather than by every application behind it. That moves session checking out of each application and into one place, which is the same argument an identity provider makes one layer up, and it is why this comes up so often with teams who have several applications and one login.
A web application firewall, as a separate add-on. F5 WAF for NGINX, previously called NGINX App Protect, is a distinct product rather than part of the Plus subscription. It filters malicious traffic before it reaches the application, and the part that usually motivates the purchase is bot defense: comprehensive protection against automated attacks and bots, which is most of what an internet-facing application receives.
Worth being clear that this is a second line item. "We need the WAF" and "we need Plus" are two purchases, and quotes that assume otherwise are a common surprise.
The rest of the Plus feature set is real and rarely the reason anyone buys:
- Active health checks. Open source NGINX notices a backend is dead when a request fails on it. Plus probes backends independently and takes them out before a user finds them.
- Configuration changes without a reload. An API-driven configuration that applies traffic changes with no reload, which matters when the upstream list changes constantly, as it does anywhere with autoscaling.
- Session persistence beyond what hashing gives you, for applications that hold state per user.
- State synchronization and failover across instances, so a pair or cluster behaves as one.
- Real-time observability, meaning per-upstream metrics rather than inference from access logs.
NGINX One is F5's packaging of the whole line, launched in 2024: NGINX Plus, App Protect WAF, the Ingress Controller, Gateway Fabric and Instance Manager under one subscription, with a SaaS console for fleet-wide visibility including instance discovery, CVE tracking by severity and certificate status. The case for it is fleet management rather than any single capability, so it lands when you have many instances and cannot answer "which of them is unpatched".
The honest guidance: start with open source. Adopt the commercial version when you can name which of the capabilities above you need, not because a product page implies the free one is a trial. In practice the question that decides it is usually whether you want authentication or bot filtering handled at the edge; if neither, open source covers most single-application deployments indefinitely.
The Kubernetes ingress confusion, and a deadline
If you arrived here from Kubernetes, the thing you have been reading about is probably not plain NGINX.
An ingress controller watches Kubernetes for routing rules and generates configuration for a proxy. Several use NGINX as that proxy, and they are separate projects with different maintainers, different feature sets and annotations that are not interchangeable. So "we use NGINX" inside a Kubernetes conversation and outside it can mean quite different things.
One of them is now retiring, and this is the most important thing on this page if you run Kubernetes. The community controller, Ingress-NGINX, is being retired: best-effort maintenance continued until March 2026, and the project states there will be no further releases, no bugfixes, and no updates to resolve any security vulnerabilities that may be discovered. Its own guidance is that anyone not already using it should not deploy it.
That is not a deprecation notice to file for later. An internet-facing component that will not receive security fixes is a dated liability, and Ingress-NGINX is one of the most widely deployed pieces of software in the Kubernetes ecosystem, which means a great many clusters are affected and many of their operators have not noticed.
If you run it, there are two questions worth answering this quarter: what you are moving to, with the Gateway API implementations being where the project points, and how long that migration takes given every routing rule and annotation in your cluster is expressed in the controller you are leaving.
When you need it
- An application server that should not face the internet directly. Most application runtimes are not built to be edge-facing, and this is the standard answer.
- TLS termination in one place, so certificates are managed once rather than in every application.
- More than one instance of anything, at which point something has to distribute traffic.
- Static content next to a dynamic application, served without waking the application at all.
When you do not
A managed platform that already fronts your application has this layer, and adding your own duplicates it.
A CDN alone, for a purely static site with no dynamic origin, is less to run.
When what you actually want is caching, look at a cache built for it. NGINX caches; Varnish is designed around it, with a configuration language for rules NGINX cannot express.
What running it involves
- TLS and certificate renewal. Automated issuance is standard now, and the automation is a thing that can break quietly until a certificate expires.
- Configuration is easy to get subtly wrong. Location matching, header forwarding and proxy buffering have behaviors that are correct and surprising. A reload with a bad config is worse than a syntax error, because a syntax error at least stops.
- Timeouts and buffer sizes. Defaults are conservative and cause mysterious failures on large uploads and slow backends.
- Security patching. It is the process facing the internet.
- Logs are the useful signal. Access and error logs are where a wrong route or a failing backend actually shows up.
Where VSHN fits
VSHN deploys, monitors and maintains NGINX on Swiss infrastructure, including the TLS, configuration and patching work above, as part of an application delivery stack rather than as a component in isolation.
If you are still deciding what to run at the edge, the useful first question is which of the four jobs is the one you actually have. It changes the answer more than the choice of software does.