I Asked My Internship Team How the App Was Hosted. Their Answer Confused Me for Weeks.
During my internship, I asked one simple question.
"How is this app hosted?"
The answer came fast.
"It is on EC2. Nginx handles routing. There is a load balancer in front."
I nodded like I understood.
I did not.
I wrote the words down: EC2, Nginx, load balancer.
At that time, I could build features. I could run the app locally. I could fix small bugs. I knew how the frontend talked to the backend, and I knew how the backend talked to the database. But when someone explained how the same app lived on the internet, it felt like I had entered a different world.
If you are a beginner developer in Nepal, you have probably felt this too. You know React, Django, Node, Laravel, or PostgreSQL. Then you open a job post and see things like AWS EC2, Nginx, load balancer, web app hosting, deployment, and production server.
Suddenly, it feels like these things are only for senior engineers.
They are not.
The problem is not that these concepts are impossible to understand. The problem is that they are usually explained too late, and often with too many heavy words. So let us break them down properly.
By the end of this guide, you should be able to explain how web apps are hosted using EC2, Nginx, and a load balancer — without pretending to understand anything.
What Hosting Actually Means
Before we talk about EC2, Nginx, or load balancers, we need to understand one basic word: hosting.
Hosting simply means your app is running on a computer that users can access through the internet.
When you are building a project, you usually run it on your own laptop. If it is a React or Next.js app, you might run npm run dev. If it is a Django app, you might run python manage.py runserver. Then you open something like localhost:3000 or 127.0.0.1:8000.
That is local development. The app works on your machine.
But there is one problem. Your friend in Kathmandu cannot open your app from their phone. Your client in Pokhara cannot use it. Your teacher cannot test it unless your laptop is running and connected in some special way.
That is not real hosting.
Imagine you built a tuition center management app in Pokhara. It works perfectly on your laptop. You can add students, track fees, and manage classes. Then the tuition center owner asks, "Can my staff open this from Kathmandu?"
That is where hosting starts.
The app must move from your laptop to a server — a computer that stays online and responds when users visit your website. In modern development, that server is rented from a cloud provider like AWS.
That is where EC2 comes in.
What Is AWS EC2?
Before cloud providers like AWS existed, if you wanted to host an app, you had two choices. You could leave your own computer running 24 hours a day, which is expensive and unreliable. Or you could buy a physical server, install it somewhere with a stable internet connection, and manage it yourself — which is even more expensive and complicated.
AWS changed this. Instead of buying hardware, you rent a computer. You turn it on when you need it, choose how powerful it should be, and pay only for what you use.
EC2 stands for Elastic Compute Cloud. In AWS, each rented computer is called an instance. So when someone says "EC2 instance," they simply mean one of these rented computers running in the cloud.
The word "Elastic" in the name means the size can change. If your app grows and needs more power, you can upgrade the instance. If traffic drops, you can scale down. You are never locked into one size.
A simple way to understand it: EC2 is like renting a computer in the cloud instead of keeping your laptop on all day.
When you create an EC2 instance, you choose things like the operating system, CPU, RAM, storage, region, and security rules. For example, you might create an Ubuntu instance on AWS, connect to it using SSH, install your app, and run it there.
Now your app is no longer only on your laptop. It is on an instance that is always online.
That is the first big step in understanding how web apps are hosted.
But there is still one problem
Your app is now running on an EC2 instance. But if your backend runs on port 5000, users would have to visit something like http://123.45.67.89:5000. That is not how real websites work. Users expect https://yourapp.com. They should not care about ports, internal processes, or server details.
This is where Nginx comes in.
What Is Nginx?
Nginx is a web server and reverse proxy. That sounds technical, so let us make it simple.
If EC2 is the building where your app lives, Nginx is the front desk.
A user comes to your website. Nginx receives the request first. Then it decides where that request should go. Maybe it is for a frontend page. Maybe it is for an API. Maybe it is for an image. Maybe it needs to go to a backend app running on an internal port.
Nginx manages all of that.
A simple way to say it: Nginx receives web requests and sends them to the right place.
What Nginx Actually Does
Let us say you have a college management system. The frontend has pages like /login, /dashboard, and /students. The backend has API routes like /api/login, /api/students, and /api/fees.
Your backend might be running internally on localhost:5000, but users do not need to see that. They only visit https://collegeapp.com.
Nginx receives the request and routes it properly. /login goes to the frontend. /api/login goes to the backend. /static/logo.png serves an image file.
So instead of exposing your app directly on an internal port, you place Nginx in front of it. Users reach your app through a clean domain, not internal port numbers they should never have to know about.
EC2 and Nginx Together
Now the setup looks like this:
User → Domain → EC2 instance → Nginx → App
This is already enough for many small projects — portfolio websites, college projects, small business websites, admin dashboards, and early startup MVPs. A single EC2 instance running Nginx can handle these comfortably.
This is the point where hosting starts feeling real. You learn how apps move from localhost to a real server. You learn how domains connect to instances. You learn how requests reach your backend. You learn how to check logs when something breaks.
But now imagine your app starts growing.
More users arrive. Your single EC2 instance starts to struggle under the load. Then one day, it crashes. Every user sees an error. Your entire app is offline — not because of a bad bug, but because one computer had a bad moment.
There is no backup. There is nothing to catch the traffic.
That is when a load balancer becomes important.
What Is a Load Balancer?
A load balancer is a system that spreads user traffic across multiple EC2 instances.
A load balancer is a traffic manager for your app.
Instead of sending every user to one EC2 instance, it distributes users across several. User 1 may go to instance 1. User 2 may go to instance 2. User 3 may go to instance 3. User 4 may go back to instance 1.
No single instance has to carry everything alone.
Think of a ticket booking website for a popular concert in Kathmandu. At 10 AM, tickets open. Thousands of users visit at the same time. If all of them hit one instance, that instance may slow down or crash entirely. But with three instances and a load balancer in front, traffic is shared and the app stays responsive.
A load balancer helps in two main ways:
First, it spreads traffic. No single instance gets overwhelmed when demand spikes suddenly.
Second, it improves reliability. If instance 1 goes down, the load balancer stops sending users there and keeps routing to instance 2 and instance 3. The full app does not go offline just because one instance has a problem.
ALB and NLB
You may hear two common terms: Application Load Balancer and Network Load Balancer.
An Application Load Balancer (ALB) works well for web apps. It understands HTTP and HTTPS traffic and can route requests based on URL paths like /api, /admin, and /images.
A Network Load Balancer (NLB) works at a lower network level. It is used when speed and low-level network handling matter more than URL-based routing.
For most beginner web developers, ALB is the first one to understand. When someone says "We use an AWS load balancer for our web app," they are almost always talking about an ALB.
Do not worry about memorizing every type right now. Just understand the purpose: a load balancer sends users to healthy instances and helps the app stay online.
How EC2, Nginx, and a Load Balancer Work Together
Now let us connect the full picture.
A common hosting setup looks like this:
User → DNS → Load Balancer → EC2 Instance → Nginx → App → Database
Here is what happens at each step:
A user visits https://myapp.com. Their browser does not know where that domain lives, so it asks DNS — the internet's address book — for directions. DNS replies with the address of the load balancer.
The load balancer checks which EC2 instances are healthy and forwards the request to one of them.
Inside that EC2 instance, Nginx receives the request. It reads the URL, figures out whether it is asking for a page or API data, and hands it to the right part of the app.
The backend does its work — querying the database, building a response — and sends the result back. Nginx passes it back to the load balancer. The load balancer passes it back to the user's browser.
That is the full path. This is exactly what confused me during my internship — not because it is impossible, but because nobody showed the complete journey clearly.
Do Nepali Startups Need EC2, Nginx, and a Load Balancer?
Not always.
Many beginners see a full architecture diagram and think every app needs it from day one. That is not true.
A small app can start with just:
User → Domain → EC2 Instance → Nginx → App → Database
This is enough for local business websites, college projects, admin dashboards, portfolio sites, small internal tools, and early MVPs.
But some apps need more careful planning from the beginning. Ticket booking apps, online exam systems, admission form portals, election result pages, and viral campaign websites can all receive sudden, heavy traffic. For them, a load balancer makes sense from the start.
The better question is not, "Should every app use a load balancer?"
The better question is: "What happens if many users arrive at the same time, or one instance fails?"
That answer tells you whether you need a load balancer now or later.
Good engineering is not about using the most complex setup from day one. Good engineering is knowing what problem each piece solves — and adding it when the problem actually appears.
Final Recap
The first time I heard "EC2, Nginx, load balancer," it sounded like a senior engineer's sentence.
Now it feels simple.
EC2 instance — a rented computer in the cloud where your app runs
Nginx — the front desk that receives web requests and sends them to the right place
Load balancer — the traffic manager that spreads users across multiple instances and keeps the app online if one fails
Together: User → DNS → Load Balancer → EC2 Instance → Nginx → App → Database
What Actually Happens When You Visit a Website
Here is the plain version first.
Your friend in Kathmandu types your app's URL and presses enter. To them, a page loads. That is all they see.
But behind that moment, a small journey happens.
Their browser does not know where your app lives — just like you might know a shop's name but not its address. So it asks for directions. DNS is the system that gives those directions. It replies with the address of the load balancer.
The load balancer is like the receptionist at a busy office. It checks which EC2 instances are available and working, then quietly forwards your friend to one of them.
Inside that EC2 instance, Nginx is waiting. Think of Nginx as the person at the front desk of that office. It reads the request — "they want the login page" or "they want this API" — and sends it to the right part of the app.
The app does its work. Maybe it checks the database. Maybe it builds a page. Then it sends the answer back.
That answer travels back through Nginx, back through the load balancer, and arrives in your friend's browser as a rendered page.
Total time: a few hundred milliseconds. To your friend, it is just a website that works.
