From Localhost to Production: What Actually Happens When You Deploy a Web Application?
journey of a React + Node.js app from your laptop → server → database → DNS → HTTPS → monitoring
From Localhost to Production: What Actually Happens When You Deploy a Web Application?
When I first started building web applications, “deployment” felt almost magical.
The application worked perfectly on my laptop. I could run the frontend, start the backend, connect to a database, and everything worked.
Then came the question:
“Okay… how do I make this accessible to everyone else?”
That is where the real journey from localhost to production begins.
In this article, we'll break down what actually happens when a web application moves from a developer's machine to a production environment, and where AWS fits into that picture.
1. The application on localhost
A typical full-stack application might look something like this:
1
2
3
4
5
6
7
User
↓
React Frontend
↓
Node.js / Express Backend
↓
PostgreSQL Database
During development, all of these components might be running on the same laptop.
For example:
1
2
3
Frontend → localhost:5173
Backend → localhost:5000
Database → localhost:5432
This is convenient for development, but obviously we can't tell every user:
“Please install Node.js, clone my repository, and run three commands before using my website.”
We need infrastructure.
2. What changes in production?
In production, the components are usually separated.
A simplified architecture could look like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
Internet
│
▼
User/Browser
│
▼
Frontend Server
│
▼
Backend API
│
▼
PostgreSQL DB
Each component now needs to be hosted somewhere that is accessible, reliable, and secure.
This is where cloud platforms such as AWS become useful.
3. Hosting the frontend
A React application isn't actually running React on the user's computer after deployment.
First, we create a production build:
1
npm run build
The development code is transformed into optimized static assets such as:
1
2
3
4
index.html
JavaScript files
CSS files
Images
These files can be hosted using services such as Amazon S3.
S3 is an object storage service, which means it can store files and make them available to applications.
For a frontend consisting primarily of static assets, this can be a very effective architecture.
We can also put a CDN such as Amazon CloudFront in front of the storage layer.
The architecture becomes:
1
2
3
4
5
6
7
8
9
User
│
▼
CloudFront
│
▼
Amazon S3
│
└── React static files
CloudFront can cache content closer to users, reducing latency and improving performance.
4. But what about the backend?
Our frontend isn't enough.
When a user logs in, creates a post, updates their profile, or requests data, the browser needs to communicate with a backend API.
For example:
1
2
3
4
POST /api/login
GET /api/users/123
POST /api/posts
GET /api/leaderboard
Our Node.js and Express application needs somewhere to run.
AWS provides several options for this, depending on the application's requirements.
For example, an application could run on:
- Amazon EC2
- AWS Elastic Beanstalk
- Amazon ECS
- AWS Lambda, depending on the architecture
A beginner-friendly mental model is:
1
2
3
4
5
6
7
8
9
React
│
│ HTTPS request
▼
Backend API
│
│ SQL query
▼
PostgreSQL
The important thing is that the frontend should not directly communicate with the database.
The backend acts as the controlled layer between the user and the database.
5. The database
Now we have another problem.
Our PostgreSQL database cannot live on our laptop anymore.
A production database needs to be persistent, protected, backed up, and accessible to the backend.
AWS provides Amazon RDS for managed relational databases.
Instead of manually managing every part of the database infrastructure, RDS can handle much of the underlying database administration.
The architecture now looks something like:
1
2
3
4
5
6
7
8
9
10
11
12
Internet
│
▼
Browser
│
┌────────┴────────┐
▼ ▼
CloudFront Backend
│ │
▼ ▼
S3 RDS
React App PostgreSQL
Now our application has a proper separation between frontend, backend, and database.
6. Where does security come in?
This is one of the most important differences between a college project and a production application.
On localhost, it is easy to accidentally do things like:
1
2
DATABASE_PASSWORD=supersecretpassword
JWT_SECRET=mysecret
and forget about them.
Doing this in a public repository is a very bad idea.
Secrets should not be hardcoded into source code.
AWS provides services such as AWS Secrets Manager for securely storing sensitive information such as database credentials, API keys, and other secrets.
We also need to think about permissions.
A production application shouldn't have unrestricted access to every AWS resource.
This is where AWS Identity and Access Management (IAM) becomes important.
The principle should be:
Give each component only the permissions it actually needs.
This is commonly called the principle of least privilege.
7. HTTPS and domains
There is another difference between:
1
http://localhost:5173
and:
1
https://myawesomeapp.com
In production, we want users to communicate with the application securely.
AWS services such as AWS Certificate Manager can be used to obtain and manage TLS certificates for supported AWS services.
We can also use Amazon Route 53 for DNS management.
Conceptually:
1
2
3
4
5
6
7
8
9
10
myawesomeapp.com
│
▼
Route 53
│
▼
AWS infrastructure
│
▼
Application
Now the application feels less like a project running on a laptop and more like an actual product.
8. Monitoring: What happens when something breaks?
Deployment isn't the end.
Imagine the backend suddenly starts returning:
1
500 Internal Server Error
How do we know?
How do we investigate?
How do we determine whether the problem is the application, server, database, or network?
This is where monitoring and logging become important.
AWS services such as Amazon CloudWatch can help collect logs, monitor resources, and create alarms.
Instead of discovering a problem because a user sends:
“Hey, your website is broken.”
we can potentially detect problems through monitoring.
9. The complete picture
Putting everything together, a simplified AWS architecture might look like:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
USERS
│
▼
Route 53
│
▼
CloudFront
│
▼
Amazon S3
React Frontend
│
│ HTTPS/API
▼
Backend Service
Node.js/Express
│
┌─────────┴─────────┐
▼ ▼
Secrets Manager PostgreSQL
│ │
│ ▼
│ RDS
│
▼
IAM / Roles
+
CloudWatch
Logs & Monitoring
This is obviously a simplified architecture. Real production systems can become significantly more complex depending on scale, availability requirements, traffic, and business needs.
But the fundamental idea remains the same.
10. Deployment is not just “putting code online”
The biggest lesson I've learned is that deployment isn't simply uploading a project to a server.
It involves answering several questions:
Where does the frontend live?
Where does the backend run?
Where is the database?
How does the application communicate securely?
How are secrets stored?
Who has access to what?
How do users reach the application?
How do we monitor failures?
Once you start thinking about these questions, cloud architecture becomes much less mysterious.
You stop seeing AWS as a collection of hundreds of confusing services and start seeing it as a set of building blocks.
Final thoughts
The journey from:
1
localhost
to:
1
https://myapp.com
is where a lot of software engineering concepts come together.
You learn about networking, databases, security, authentication, infrastructure, deployment, monitoring, and scalability — all through the process of making one application available to real users.
And that's probably the most useful way to learn cloud engineering:
Don't start by memorizing AWS services. Start with an application and ask what it needs to work reliably in the real world.
Then choose the services that solve those problems.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article