Nginx is the doorman in front of your application, and most outages start there.
Your application does not talk to the internet directly. Something takes the request, checks the certificate, decides which application should answer, and serves the logo without waking anything up. On most Indian servers we work on, that something is Nginx.
It is the least interesting part of a stack. We look there first when a site is slow, shows a certificate warning, or serves a page belonging to a different application.
Nginx is a web server that sits in front of everything else. It handles the encrypted connection, passes the request to the right application, serves images and files itself, and decides what happens when the application behind it is not answering. One server can host several sites this way, each with its own domain.
Where it earns its place.
What it is doing for you
- Terminating SSL, so certificates live in one place
- Routing a domain to the right application on the machine
- Serving images, files and built assets without touching the app
- Holding requests while a deployment restarts the application
- Limiting how often one address may hit a login or an OTP endpoint
- Redirects, from the old site’s URLs to the new ones
The configuration work we do
Usually on a server somebody else set up, where the original file has been copied from an answer online and edited in a hurry.
- Read the config
- Fix routing
- Certificates
- Limits and caching
- Logs
- Certificates renewed automatically rather than by a diary reminder
- Upload limits raised so a scanned bill stops failing at 1 MB
- Timeouts set to match how long the slow report actually takes
- Caching for files that never change, off for pages that do
- Compression, so a listing page is not sent in full over a mobile network
- Logs going somewhere a person will read
Where it goes wrong
These five account for most of the Nginx tickets that reach us.
- A certificate that expired because renewal was never tested
- A gateway error that is the application crashing, not Nginx
- Upload size left at the default, so large files fail silently
- A second site added that quietly takes over the first one’s traffic
- Rules for a removed application still routing traffic nowhere
A gateway error almost never means Nginx is broken. It means the thing behind it stopped answering, which is a different investigation.
What sits around it
Routing and encryption are all it does. Treating it as your security layer is a mistake we see often.
- Cloudflare in front for DNS, caching and traffic protection
- Docker behind it, with Nginx as the only thing exposed
- Several application servers behind one Nginx where load needs sharing
- Ubuntu underneath, patched on a schedule somebody owns
Rate limits slow a crude attack. They are not a web application firewall, and we would rather say so than let you believe the box is ticked.
When this is the right choice.
- Your application runs on a server you or we administer
- Several sites or applications share one machine
- You want hosting costs predictable, without a per-request platform bill
- SSL, redirects and upload limits are currently nobody’s job
- An existing server was configured once and never revisited
When it is not.
- Applications on Vercel, Netlify or App Runner, where the platform already does this and a second layer adds nothing
- A team with nobody to patch the server, unless that is work you hand to us
- Replacing a cloud load balancer that is already working and managed for you
- Static sites on object storage with a CDN in front, which need no server at all
- Use as your only defence against attack traffic, which is a different tool
Questions we are asked about it.
Do we need Nginx if we are on AWS or DigitalOcean?
It depends on how you run there. On a plain virtual machine, yes, something has to front the application. If you use a managed load balancer and a container service, that job is already done and adding Nginx is extra work for nothing.
Our site shows a 502 error. Is that Nginx?
Almost never. A 502 means Nginx asked your application for a response and did not get one, so the application has crashed, is restarting, or is stuck on a query. We look at the application logs first, not the Nginx file.
Who renews the SSL certificate?
It should be automatic, through Let’s Encrypt and a renewal job on the server that is tested once rather than trusted. Where certificates are bought from a vendor, somebody has to own the date, and that should be written down rather than remembered.
Can one server host several of our applications?
Yes, and Nginx is how each domain finds the right one. The limit is memory and how noisy the busiest application is. Keeping a customer-facing site on the same box as a heavy internal report is the arrangement that usually needs splitting.
Nginx or Apache?
For new work we use Nginx, largely because it handles many idle connections cheaply and the configuration is easier to read later. If you already run Apache and it works, moving is not a project worth funding on its own.
Can you work on a server we already have?
Yes. Reviewing an existing configuration, fixing routing and certificates, and writing down what is actually running on the machine is routine work here, with no migration involved.
Services that use it.
What it sits with.
Not sure Nginx is the right choice?
Tell us what the software has to do and who opens it. If something else fits better, we will say so, and say why.
- No obligation
- We reply the same working day
- Your details stay private