NGINX was written by Igor Sysoev and first released in October 2004. He built it to solve the "C10k problem": serving ten thousand concurrent connections on one machine, which the process-per-connection web servers of the time could not do without running out of memory. That origin explains everything about how NGINX behaves today. It is event-driven, it uses very little memory per connection, and it is happiest when it is handing work to something else.
Since then it has become one of the two or three most-used web servers on the internet, and the software behind a large share of the reverse proxies, CDNs and API gateways that sit in front of other servers. F5 acquired NGINX Inc in 2019; the open-source project continues, alongside the commercial NGINX Plus and the NGINX Unit application server.
How Does NGINX Work?
NGINX runs a small set of processes rather than one per connection. A master process reads the configuration, binds to the ports and starts the others; it is the only one that needs root. A few worker processes do the actual work: each one runs an event loop that handles thousands of connections at once, waiting on network events instead of blocking on each request. The usual configuration is one worker per CPU core.
Two helper processes look after the on-disk cache. The cache loader runs at startup to read the existing cache into memory and then exits. The cache manager runs periodically to expire and prune cached content so the cache stays within its size limit.
Because a worker never blocks waiting for one client, NGINX handles slow connections, keep-alive connections and thousands of idle clients with a small, predictable memory footprint. That is the C10k answer, and it is why NGINX is so often put in front of an application server: it absorbs the connections, serves static content directly, and passes only the dynamic requests upstream.
What NGINX is used for
- Web server. Serving static files (HTML, images, CSS, JavaScript) directly from disk, very quickly.
- Reverse proxy. Accepting requests on behalf of an application server (PHP-FPM, Node.js, Python, Ruby) and forwarding them, so the application never faces the internet directly.
- Load balancer. Spreading requests across several upstream servers with health checks, so one busy or failed server doesn't take the site down. See what is load balancing.
- HTTP cache. Storing responses from the upstream server and serving repeats from disk, so the application does the work once.
- TLS termination. Handling HTTPS so the application behind it can speak plain HTTP.
- Mail proxy. Less common now, but NGINX can proxy IMAP, POP3 and SMTP too.
On a typical VPS, NGINX does the first two: it serves the static files and proxies everything else to PHP-FPM or a Node process. That is the setup Ghost, most Node apps and many Laravel deployments use.
The configuration file, briefly
NGINX is configured in a text file, usually nginx.conf with per-site files in sites-available. The building blocks are directives inside blocks: an http block, server blocks for each hostname, and location blocks that decide what happens to a given URL path. A location can serve files from a root directory, proxy_pass to an upstream, return a redirect, or apply caching headers. It reads cleanly once you've seen one, and it does not support .htaccess files, which is the first thing people notice when they move from Apache.
Nginx vs Apache Usage Stats
Apache was the first widely used open-source web server and for two decades it was the default. It is process- or thread-based, extremely flexible, and configured per directory through .htaccess files, which is why shared hosting standardised on it.
By usage, NGINX overtook Apache some years ago. W3Techs' running survey of web server software puts NGINX ahead of Apache among all sites, with Cloudflare's edge servers and LiteSpeed also holding large shares; the exact figures move month to month, so check the survey for today's numbers. Among the highest-traffic sites the gap is wider, because NGINX's connection handling is what those sites need.
The practical difference: Apache is easier to configure per site and supports .htaccess; NGINX is faster under high concurrency and uses less memory. Many setups use both, with NGINX in front as a reverse proxy and Apache behind it.
NGINX vs LiteSpeed
LiteSpeed Web Server takes a third approach: it is event-driven like NGINX, but it reads Apache configuration files and .htaccess, so it drops into an Apache-based hosting stack without changes. It also has a built-in page cache, LSCache, with plugins for WordPress and other platforms. That combination is why shared and managed hosting, including all of our UK cloud hosting plans, tends to run LiteSpeed rather than NGINX: you get NGINX-class concurrency with Apache compatibility and caching in the box. See what is LiteSpeed Web Server and what is LSCache.
On a VPS where you control the stack, NGINX is the common choice for proxying Node, Python and Ruby applications, and it's what we set up in front of Ghost on our managed Ghost servers.
NGINX FAQs
Why am I seeing NGINX?
If a page shows "Welcome to nginx!" or an error page with "nginx" at the bottom, the server in front of that site is NGINX and something behind it isn't responding. A 502 Bad Gateway means NGINX could not reach the application server; a 504 means it timed out waiting for it. On your own server, check the application process is running. On someone else's, it's their problem. Our guide to fixing a 502 Bad Gateway error covers the WordPress case.
Is NGINX going end of life?
No. NGINX open source is actively developed and F5 continues to release it. In 2024 one of its long-time developers started a fork called freenginx after a disagreement inside the project, but the main project did not stop.
Is NGINX trustworthy?
Yes. It is mature, open source, audited by a very large user base and used by many of the biggest sites on the internet. As with any web server, keep it updated.
How do I get rid of NGINX?
If you mean the default welcome page, add a server block for your site or point the root at your site's files. If you mean removing it from a server, stop the service and uninstall the package (apt remove nginx on Ubuntu), then install whatever replaces it. If you're on a managed plan, you don't have NGINX to remove; the web server is ours to run.
Do I need NGINX on shared hosting?
No. On a managed hosting plan the web server is chosen and run by the host. Ours run LiteSpeed. NGINX is something you'd install and configure yourself on a UK VPS with root access.
Hosting that keeps up
Fast, managed UK hosting with a team that answers.
NVMe SSD, LiteSpeed and free managed migration from your current host, run by a UK support team around the clock.