Wait… What’s NGINX — And Why Is Everyone Using It?

Harish SelvaHarish Selva
5 min read

🚀The Deployment Nightmare :

A few weeks ago, I was working on a simple web app project. Everything worked fine on localhost, but the moment I tried to deploy it, I found myself tangled in CORS issues, port conflicts, and a general sense of "this is not how production works."

That’s when my colleague said:

“Why don’t you use NGINX?”

I had heard of NGINX before mostly in tutorials and deployment videos — but I had never used it, nor did I understand what it truly did.
Turns out, NGINX is the invisible superhero behind many of the world’s fastest websites, including Netflix, Dropbox, and WordPress.com.

⚡ The C10K Problem & NGINX’s Secret Sauce :

As I started researching NGINX, I stumbled upon the term C10K problem — short for “Concurrent 10,000 connections.”
In the early 2000s, most web servers could not efficiently handle thousands of users connecting at the same time. Traditional web servers like Apache followed a thread-per-connection model — meaning for every user, the server spun up a separate thread.

Imagine 10,000 users each getting a thread — that’s 10,000 threads!
Now imagine your server trying to juggle all those with limited CPU and memory. 🔥💥

NGINX was a game-changer. Developed by Igor Sysoev in 2004, it used a completely different architecture:

  • Asynchronous (Executes tasks without waiting for previous ones to finish)

  • Event-driven (Code is triggered in response to specific events)

  • Non-blocking (Continues running other tasks without getting delayed)

With this approach, NGINX could serve 10,000+ clients using just a few threads — a revolution in web performance.

Wait, What is Nginx?

Nginx (pronounced "engine-x") is an open-source web server that also acts as a reverse proxy, load balancer, and content cache Wait, wait — don’t get overwhelmed. In simple words: It handles user requests, makes sure your website delivers content efficiently. It’s like receptionist of your website.

Various roles Nginx play!

RoleDescriptionReal-World Analogy
🔌 Web ServerServes static files like HTML, CSS, JS."Here's your brochure."
🔁 Reverse ProxyForwards client requests to backend (like Node.js)."Let me pass your message to the chef."
⚖️ Load BalancerDistributes traffic across multiple servers."Too crowded here, go to the next counter!"
📦 Caching LayerStores frequently accessed data for faster delivery."Here's your favorite dish, already hot!"

Why Nginx?

  • Speed: It’s non-blocking and event-driven—super efficient.

  • Scalability: It can handle thousands of simultaneous connections.

  • Security: Acts as a gatekeeper, hiding internal architecture.

  • Simplicity: One config file can do wonders.

  • Flexibility: Use it for static sites, dynamic apps, APIs, or all of them at once.

And the best part? Many of these benefits work by default

But I Didn’t Configure Anything. How Am I Getting These Benefits?

Good question! Even with zero extra config, just by placing your files behind NGINX:

  • You get fast static file delivery.

  • You get basic security headers.

  • You get connection handling that won’t choke under load.

These are default perks, and advanced config makes it even better. Installing NGINX (Don’t Worry, It’s Easy)

🧰 Installing NGINX (Step-by-Step) :

On Ubuntu/Debian:

sudo apt update
sudo apt install nginx

On Windows:

Download the binaries from nginx.org , unzip and run. Simple as that.

Installed Nginx, but how do we tell NGINX what to do?

🗂️ Let’s Configure Your Web App :

The main config file is usually located at:

/etc/nginx/nginx.conf     ← (Linux)
conf/nginx.conf           ← (Windows)

It might look scary at first but breathe, we’re not rewriting the world here.😅
At its core, a basic NGINX config looks like this:

server {
    listen 80;
    server_name yourdomain.com;

    location / {
        root /var/www/html;
        index index.html;
    }
}

Let’s break that down:

  • listen 80; — NGINX listens on port 80 (default for HTTP).

  • server_name — Your domain (or IP address for local dev).

  • location / — What to do when someone visits your site.

  • root — Folder where your site lives.

  • index — Default file to serve.

Deploying Your Web App (The Simple Way)

Let’s say your frontend files (like index.html, style.css, etc.) are inside:

/home/you/my-web-app

You just need to tell NGINX to serve from there. Modify your config:

server {
    listen 80;
    server_name localhost;

    location / {
        root /home/you/my-web-app;
        index index.html;
    }
}

After saving changes, run:

sudo nginx -t     # ✅ Test if config is valid
sudo systemctl restart nginx   # 🔄 Restart NGINX

🥳Your web app is now live on http://localhost.

To check if NGINX is running:

sudo systemctl status nginx

To stop/start manually:

sudo systemctl stop nginx
sudo systemctl start nginx

I don’t want to complicate things by talking about backend connectivity right now — the above steps are enough for deploying a simple web app.

💡Why You Shouldn’t Be Scared of NGINX

✅ It’s beginner-friendly once you try.
✅ Default behavior is already optimized for speed and performance.
✅ A single config file gives you total control over how your app is served.
✅ Whether you’re serving a simple portfolio or a full-blown SaaS — NGINX scales with you.

I started with zero clue about deployment. Thanks to NGINX, I now feel confident about making my apps production-ready.

If you’re stuck or overwhelmed, just remember: NGINX doesn’t bite.

Try it. Break it. Fix it. That’s how we learn. 💪

Happy Deploying! 🚀
If this helped, consider sharing it with your fellow dev friends.
Have questions or a story about your first NGINX deploy? Drop it in the comments — I’d love to chat!

0
Subscribe to my newsletter

Read articles from Harish Selva directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

Harish Selva
Harish Selva