The specific, extremely common software your engineers run as a reverse proxy and load balancer.
Why it exists
Teams need a proven, fast piece of software to serve files, terminate HTTPS, and act as that front door, rather than writing one. NGINX exists as the widely used tool that does exactly this, which is why it sits in front of so many systems.
How it actually works
NGINX (say "engine-x") is a widely used piece of infrastructure software. It receives incoming web traffic and does the front-door jobs: routing requests to the right servers, balancing load across them, handling HTTPS, and serving cached content fast.
You'll hear it named constantly because it's everywhere. When someone says "it's an NGINX config," they mean a settings change at that front door, not in the application itself.
A senior PM walks you through it
A junior PM, stuck
A redirect is broken: an old link is meant to send people to the menu and it does not. The dev says it is just an NGINX rule, no app deploy needed, and can ship today. I have to decide whether to let it go out, but I cannot read the config, so I cannot tell if "no deploy" is real or wishful.
The dev is right that this lives at the front door, not in the app, and the config makes that clear in a five minute read. Below is the nginx.conf for tiffinbox.com, the rulebook for what happens to a request before it ever reaches the application. Once you can read the blocks you will see the redirect is one line here, and you will know the one caution worth naming before it ships.
Treating "no app deploy" as "no review needed." A one-line NGINX change still routes real traffic; read what it does before you let it ship, even though it skips the build pipeline.
Waving through a 301 without checking the target. A permanent redirect is cached hard by browsers, so a wrong destination follows users around even after you fix the line.
Assuming anything in nginx.conf is an application change. The /api block forwards to the app, but the redirect and file-serving lines are the front door's own job; they change at that layer, not in the codebase.
Confusing where the front door ends and the app begins. proxy_pass hands /api requests to the app servers; the return 301 line is resolved by NGINX itself and never reaches them, which is exactly why it needs no app deploy.
Tell the dev: "The redirect is a one-line return 301 in the NGINX config at the front door, so it applies on a config reload with no app build or deploy, it can go today. One caution: 301s are permanent and get cached by browsers, so let's confirm the target path is /menu before it ships." You read an nginx.conf, told the front-door layer apart from the app, and cleared a same-day change with the one risk named.
Where a PM meets this
Hearing NGINX named just means the request is about that front-door layer; "NGINX change" is usually a config tweak, often quick.
Useful only as recognition: you won't configure it, but knowing what it is keeps you oriented in infra conversations.
Hear it in a meeting
"That redirect's an NGINX rule, we don't need an app deploy for it."