There is a particular moment every frontend developer eventually encounters.
You have built the application. It works beautifully on localhost:4200. Your React, Angular, or Vue frontend is polished. Your Node.js API works. The database works. Everything works.
Then someone asks:
“Can you show me the live application?”
And suddenly, you are reaching for your laptop.
This post is for exactly that situation.
I remember this from my college days. Our final-year exams were approaching, and just before the exams, the university conducted the viva and project presentations. Technically, the presentations happened at our colleges, but the examiners were sent by the university.
I was leading a group of five, and there were several groups presenting their final-year projects.
And believe me, every single project was demonstrated on the developer's own laptop, running locally.
localhost.
The examiner would sit there, the developer would open the laptop, start the frontend, start the backend, make sure the database was running, and then say, “Sir, this is our project.”
It always struck me as a little strange.
We had spent months building these applications, but when it was finally time to show them, they were still trapped inside our laptops.
And I think this is a real gap that many developers don't even realise they have.
Not because deploying an application necessarily requires some complicated cloud architecture. It doesn't.
You don't need to become a DevOps engineer just to put your project on the internet.
You simply need to take that extra step and ask:
“What happens if this thing I've built actually goes live?”
Because the moment your application moves from localhost to a real URL, something changes.
It stops being “some code I built on my computer.”
It becomes something people can actually open, use, share, test, break, recommend, and remember.
It starts looking less like a college project and more like a product.
And that shift is much more important than most developers realise.
Maybe you already know Firebase Hosting. Maybe you have deployed something to Vercel. Maybe you have used Hostinger and know your way around a VPS. But the moment someone says GCP, AWS, Compute Engine, EC2, Cloud Storage, S3, Cloud Run, containers, IAM and networking, it starts sounding less like web development and more like a job for someone who has memorised the entire cloud console.
It is not.
The trick is to stop thinking about cloud providers as hundreds of unrelated services.
There is a much simpler mental model.
Once you understand that model, AWS and GCP stop looking like completely different worlds.
First: what does “cloud hosting” actually mean?
At the simplest level, your application needs somewhere to live.
There are two very different questions hidden inside that sentence:
What exactly am I putting online?
and
Who is responsible for keeping the computer running?
Those two questions explain most of the cloud-hosting landscape.
Suppose you have a frontend application.
After running:
npm run build
you might end up with something like:
dist/
├── index.html
├── styles.css
├── main.js
├── assets/
└── ...
Those are just files.
A browser can download them and run the JavaScript.
But a Node.js backend is different.
A Node.js server actually needs a runtime. Something has to start Node, keep it alive, accept requests and deal with crashes, scaling and networking.
That distinction is the foundation of everything that follows.
The easiest mental model: three ways to host
For a frontend developer, think about hosting as three broad approaches.
| Approach | What you get | What you manage | Examples |
|---|
| Managed static hosting | A place to serve built HTML/CSS/JS | Almost nothing | Firebase Hosting, Vercel |
| Virtual machine | A blank Linux computer | Almost everything | GCP Compute Engine, AWS EC2, Hostinger VPS |
| Managed application/container platform | A place to run your application without managing the server yourself | Your application/container | Google Cloud Run and similar services |
This is where things become much easier.
A Hostinger VPS, a GCP Compute Engine VM, and an AWS EC2 instance are conceptually very close.
A Firebase Hosting site, an S3 static website, and a static frontend deployed through another managed hosting service solve a different problem.
And something like Cloud Run sits somewhere else again: you provide an application/container and the platform takes care of much of the infrastructure underneath it.
Wait... isn't a VPS already “cloud”?
Yes.
And this is one of the reasons cloud terminology can be confusing.
When you rent a Hostinger VPS, you are essentially getting your own virtual Linux machine.
You can SSH into it.
You can install Node.js.
You can install Nginx.
You can run:
pm2 start server.js
You can configure domains.
You can configure SSL.
You can restart services.
You can inspect logs.
You can break everything at 2 AM and then discover that the problem was one line in an Nginx configuration file.
That last part is optional, but surprisingly educational.
Conceptually, GCP and AWS can give you the same kind of machine.
On GCP, you use Compute Engine.
On AWS, you use EC2.
So the mental map looks like this:
| What you already know | GCP | AWS |
|---|
| VPS / virtual Linux machine | Compute Engine | EC2 |
| Object/file storage | Cloud Storage | S3 |
| Managed application/container hosting | Cloud Run | AWS has several services in this category, such as ECS/Fargate |
| Managed frontend hosting | Firebase Hosting | Various AWS/frontend hosting options |
The names change.
The underlying ideas do not.
So what is a “bucket”?
This is another word that makes cloud sound unnecessarily mysterious.
A bucket is essentially a storage container for files.
Think of it as a cloud storage area designed for applications rather than a folder sitting on your laptop.
For example, a bucket might contain:
images/
avatars/
videos/
backups/
reports/
documents/
GCP calls its object-storage service Google Cloud Storage.
AWS calls its object-storage service Amazon S3.
So:
GCP Cloud Storage bucket ≈ AWS S3 bucket
This does not mean they are literally the same product. It means they occupy the same conceptual place in the architecture.
And this distinction matters:
A bucket is fundamentally a storage system.
It is not a Linux server.
You do not SSH into an S3 bucket.
You do not open a terminal inside a Cloud Storage bucket and run:
node server.js
It has no job running there waiting for your Node.js application.
That is the key difference.
Then why do people talk about putting websites in buckets?
Because a frontend built with React, Angular, Vue or plain HTML/CSS/JS can be nothing more than a collection of static files.
For example:
index.html
main.js
styles.css
logo.png
The browser downloads those files.
No Node.js process is required to render the page.
So the deployment can look conceptually like this:
Your laptop
|
| npm run build
v
Compiled frontend files
|
v
Cloud storage / static hosting
|
v
Browser
That is fundamentally different from:
Browser
|
v
Nginx
|
v
Node.js
|
v
Database / APIs
The first is primarily serving files.
The second is running an application.
Firebase Hosting suddenly makes more sense
If you have used Firebase Hosting, you have already experienced the easier side of this architecture.
You might run:
firebase init
configure your hosting directory and then:
firebase deploy
And... that's it.
No Ubuntu installation.
No PM2.
No Nginx configuration.
No manually maintaining a web server.
That is why Firebase Hosting feels so dramatically easier than a VPS.
The infrastructure still exists somewhere underneath.
You simply aren't being asked to operate most of it yourself.
And this is an important distinction:
Firebase Hosting is not the same thing as manually creating a Google Cloud Storage bucket and treating that bucket as your website server.
Firebase provides a managed hosting experience.
That is exactly why it is so attractive to frontend developers.
Now imagine doing the VPS approach on GCP
Suppose you want the exact environment you had on Hostinger.
You could create a GCP project and then provision a Compute Engine VM.
The VM is your server.
You connect to it through SSH.
Inside that machine, you can do familiar things:
sudo apt update
sudo apt install nginx
Install Node.js.
Clone your application:
git clone <your-repository>
Install dependencies:
npm install
Run your Node application:
pm2 start server.js
And configure Nginx to proxy requests to something like:
localhost:3000
At this point, you are essentially using GCP as a VPS provider.
There is nothing wrong with that.
In fact, it is a very useful way to understand the relationship between traditional hosting and cloud infrastructure.
The important question is:
Why use a giant cloud platform if you are going to operate it exactly like a VPS?
That is where the next level begins.
The cloud-native approach: stop managing the machine
Imagine your Node.js application is packaged as a container.
Conceptually, your container says:
“This is my application. Here is the runtime it needs. Here is how it starts.”
For example, a simplified Dockerfile might look like:
FROM node:20
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
EXPOSE 8080
CMD ["node", "server.js"]
Now you can give that application to a managed service such as Google Cloud Run.
Instead of saying:
“Here is a Linux machine. Please let me configure it.”
you are effectively saying:
“Here is my application. Please run it.”
That is a major conceptual shift.
With a traditional VM, you manage the server.
With a managed container platform, you focus much more on the application.
What happens when you deploy to Cloud Run?
A command such as:
gcloud run deploy --source .
can trigger a managed deployment workflow.
Conceptually, the platform takes your source, builds the application into a deployable container, stores the resulting image in cloud infrastructure, and deploys it as a Cloud Run service.
You do not normally need to configure an Nginx reverse proxy yourself.
You do not need to install PM2 manually.
You do not need to maintain an Ubuntu machine yourself.
The platform manages much more of the underlying infrastructure.
This is much closer, conceptually, to the experience frontend developers are used to from services such as Firebase Hosting and Vercel.
The difference is that Cloud Run is designed specifically to run applications and services, not merely serve static frontend files.
Now the really important question: where does my Node.js + frontend application go?
Suppose you have:
Frontend
|
| Angular / React / Vue
|
v
Compiled HTML/CSS/JS
and:
Backend
|
| Node.js / Express
|
v
API
They do not have to be hosted in the same place.
In fact, separating them is extremely common.
One possible architecture is:
USERS
|
v
Frontend Hosting
HTML / CSS / JavaScript
|
v
Node.js API
|
v
Database
Your compiled frontend could live on Firebase Hosting or another static hosting platform.
Your Node.js backend could run on Cloud Run.
Your images and other large files could live in Cloud Storage.
Your database could be a completely separate managed database service.
Suddenly “the cloud” is not one giant magical place.
It is simply several specialized services connected together.
GCP vs AWS: the names change, the architecture doesn't
The same mental model works remarkably well when switching providers.
| What you need | GCP | AWS | Simple explanation |
|---|
| Virtual machine | Compute Engine | EC2 | A Linux computer you manage |
| Object storage | Cloud Storage | S3 | Store files and objects |
| Managed containers | Cloud Run | ECS/Fargate and related services | Run applications without managing a traditional server |
| Static frontend hosting | Firebase Hosting / other options | S3 + CloudFront or other frontend services | Serve built frontend assets |
Now imagine an examiner or interviewer asks:
“How would you deploy a Node.js application on AWS?”
You do not need to panic and memorise 47 AWS services.
Ask yourself one question:
Do I want to manage a machine?
If yes, you're looking at something like EC2.
If you want a more managed application platform, you start looking at services such as ECS/Fargate and related managed compute options.
The underlying architectural decision remains the same.
S3 is not “AWS's version of a VPS”
This misconception causes a lot of confusion.
S3 is primarily object storage.
EC2 is compute.
Those words are worth remembering:
Storage is where files live.
Compute is where programs run.
That distinction alone will take you surprisingly far in cloud understanding.
For example:
S3
└── index.html
└── main.js
└── styles.css
└── images/
EC2
└── Linux
└── Node.js
└── Nginx
└── PM2
└── Your application
One is primarily a place for objects.
The other is a computer running software.
So what should you actually use?
Here is the practical decision table.
| Your situation | Sensible starting point |
|---|
| Pure HTML/CSS/JS website | Static hosting |
| Compiled React/Angular/Vue frontend | Firebase Hosting, Vercel or another static hosting platform |
| Frontend + simple Node.js API | Static frontend + managed backend such as Cloud Run |
| Need complete control over Linux | GCP Compute Engine / AWS EC2 / VPS |
| Need to store images, videos, backups or files | Cloud Storage / S3 |
| College project that needs a live URL | Managed hosting is usually the easiest route |
| Production backend where you don't want to maintain Linux manually | Managed application/container platform |
| Need unusual OS-level configuration | VM/VPS |
The best cloud service is not the one with the most impressive-sounding name.
It is the one that gives you exactly the amount of control you actually need.
And this matters enormously for students
There is another reason to learn this.
A surprisingly large number of student projects technically work but are never actually demonstrated as products.
The examiner sees:
npm start
localhost:4200
And suddenly the impressive AI recommendation engine, database integration, authentication system and beautiful UI are trapped inside one laptop.
That is a missed opportunity.
A live deployment changes the conversation.
Instead of saying:
“Sir, this is my project. It works on my laptop.”
you can say:
“Here is the production URL.”
That tiny difference changes the perception of the project.
The same applies when applying for jobs.
A resume saying:
“Built an e-commerce application using Angular, Node.js and MongoDB.”
is one thing.
A recruiter being able to click:
Live Demo
is something else entirely.
You have moved from describing a project to showing evidence that it exists.
That is one of the simplest ways to make a project feel more real.
The simplest cloud map to remember
Forget the giant cloud diagrams for a moment.
Remember this:
CLOUD
|
+--------------+--------------+
| | |
v v v
STORAGE COMPUTE MANAGED APP
| | |
v v v
GCS / S3 GCE / EC2 Cloud Run /
ECS/Fargate
Then ask:
Do I need to store files?
Think bucket/storage.
Do I need a computer I control?
Think VM/EC2/Compute Engine/VPS.
Do I need to run an application without managing the whole machine?
Think managed application/container service.
And for a normal compiled frontend?
Think static hosting.
That is the map.
The cloud console looks complicated because it exposes a huge universe of possibilities.
You do not have to use the whole universe.
You just need to identify which problem you actually have.
As a note, keep this with you:
“For a static frontend, I wouldn't provision a VM just to serve compiled HTML, CSS and JavaScript. I'd use managed static hosting. For the Node.js API, if I don't need OS-level control, I'd prefer a managed container platform such as Cloud Run. If I actually need full Linux-level control, then I'd provision a Compute Engine VM. For application assets and uploaded files, I'd use object storage such as Cloud Storage.”
Now you're someone who understands why the services exist.
And that is the real goal.
You do not need to become a cloud engineer overnight.
You just need to stop thinking of AWS and GCP as giant confusing websites and start seeing them as collections of familiar building blocks:
files, computers, applications, networks and managed services.
Once you see those building blocks, the names become much easier.
Now comes the interesting part: when you have a real Node.js + frontend project sitting on your laptop, how would you personally choose between a VPS, Compute Engine, S3/Cloud Storage, Firebase Hosting, Cloud Run or something like Vercel?
What would you deploy first — and why?
Shakeeb
Rab raakha 👋
slug:
cloud-hosting-explained-frontend-developers-gcp-aws-vps-cloud-run
og title:
Cloud Hosting Explained for Frontend Developers – GCP, AWS, VPS, Buckets & Cloud Run
og description:
Confused by GCP, AWS, VPS, S3, Cloud Storage, buckets and Cloud Run? This beginner-friendly guide explains cloud hosting for frontend developers, including how to deploy built HTML/CSS/JS frontends and Node.js backends without getting lost in cloud complexity.
keywords:
cloud hosting,
cloud hosting for beginners,
cloud hosting for frontend developers,
cloud computing for frontend developers,
GCP for beginners,
Google Cloud Platform,
AWS for beginners,
Amazon AWS,
GCP vs AWS,
VPS vs cloud hosting,
Hostinger VPS,
GCP Compute Engine,
AWS EC2,
Google Cloud Run,
AWS S3,
Google Cloud Storage,
cloud storage bucket,
what is a cloud bucket,
S3 bucket,
GCP bucket,
Cloud Run Node.js,
Node.js cloud hosting,
Node.js deployment,
deploy Node.js app,
deploy frontend app,
frontend deployment,
static website hosting,
static hosting,
Firebase Hosting,
Firebase vs GCP,
Vercel vs cloud hosting,
React deployment,
Angular deployment,
Vue deployment,
HTML CSS JavaScript hosting,
host compiled frontend,
frontend and backend hosting,
full stack cloud hosting,
cloud hosting explained,
cloud computing explained,
AWS EC2 vs S3,
GCP Compute Engine vs Cloud Run,
VPS vs EC2,
VPS vs Compute Engine,
S3 vs Cloud Storage,
serverless hosting,
managed hosting,
cloud deployment for students,
student project deployment,
deploy college project,
live project for interview,
localhost to production,
deploy project online,
cloud deployment for beginners,
cloud architecture for beginners
