Sometimes the fastest way to understand infrastructure is to stop renting it and start building it.
I Wasn't Looking for a VPS
I was scrolling through X one evening when a post stopped me.
"Tech bro to Tech bro.
If you have a passion for building side projects, get yourself a VPS."
At first, I smiled and kept scrolling.
Then I paused.
The post was simple, but it left me with a question I couldn't answer.
Do I actually understand what a VPS is?
I've deployed applications before.
I've connected GitHub repositories to hosting platforms.
I've watched CI/CD pipelines push my code into production.
I've even managed servers from dashboards.
But if someone asked me to explain what actually happens inside a VPS, I wouldn't have been confident enough to answer.
Instead of saving the post and moving on, I decided to follow its advice.
I opened Google Cloud and started building my own VPS.
My Goal Wasn't to Deploy an Application
I wasn't trying to launch a startup.
I wasn't migrating an existing project.
I wasn't even trying to host a website.
My goal was much simpler.
I wanted to understand the infrastructure that developers talk about every day.
That meant:
- Creating my own virtual machine.
- Connecting to it through SSH.
- Installing Docker.
- Running my first container.
- Understanding why every step mattered.
I also made myself one promise.
I wouldn't run a command I didn't understand.
That single decision completely changed the way I approached this journey.
My First Realization
The first thing Google Cloud gave me wasn't Docker.
It wasn't Linux.
It wasn't even a VPS in the way I had imagined it.
It gave me a computer.
Not a physical one sitting on my desk, but a virtual computer running inside one of Google's data centers.
That realization sounds obvious now.
It wasn't obvious to me then.
Once that clicked, everything else started making more sense.
Meeting Linux Through SSH
The first time I connected through SSH, I was greeted by something that looked intimidating.
Just a blinking cursor.
No desktop.
No icons.
No buttons.
Just a terminal waiting for instructions.
Ironically, that simplicity became one of my biggest lessons.
Every command I typed had a purpose.
Instead of clicking through menus, I was talking directly to the operating system.
Little by little, the terminal became less mysterious.
Then Came Docker
This was the part I had been waiting for.
I'd seen Docker commands countless times before.
docker pull
docker run
docker ps
I knew how to copy them.
I didn't know what they were actually doing.
This time, I wanted to understand.
One idea immediately changed how I thought about Docker.
An image is a blueprint.
A container is a running instance created from that blueprint.
It sounds simple.
But understanding that relationship made the rest of Docker feel much less intimidating.
Running My First Container
Eventually, it was time.
I ran my first Docker container.
Then I opened my browser.
It worked.
Seeing that page load wasn't only exciting because it eventually worked.
It was exciting because, for the first time, I understood what had just happened.
Google Cloud was running my Virtual Machine.
Ubuntu was running inside that Virtual Machine.
Docker was running on Ubuntu.
My container was running inside Docker.
The browser was talking to that container through an exposed port.
Those weren't isolated concepts anymore.
They were pieces of the same puzzle.
The Questions That Slowed Me Down
I didn't spend most of my time typing commands.
I spent most of my time asking questions.
- What exactly is a container?
- Why do containers exist if we already have Virtual Machines?
- Why does Docker need images?
- What does -p 8080:80 actually mean?
- Why can't I just use localhost?
Each answer led to another question.
Looking back, I'm glad I didn't skip those moments.
Understanding grows from curiosity, not from copying commands.
What I Learned
When I started this journey, I thought I was learning Docker.
I wasn't.
I was learning how modern infrastructure fits together.
Docker just happened to be one piece of that puzzle.
The biggest lesson wasn't technical.
It was about how I learn best.
Documentation tells you what to do.
Building teaches you why you're doing it.
And once you understand the "why," the commands become much easier to remember.
What's Next
Running my first container answered one question.
It created ten more.
In Part 2, I'll explore Docker in more depth.
Not by repeating the documentation, but by answering the questions I kept asking while building.
We'll look at:
- Why containers exist.
- Images versus containers.
- Why Docker became so popular.
- The Docker commands I actually use and why they matter.
Because this journey isn't about collecting commands.
It's about building a mental model that makes those commands finally make sense.
Before You Go
If you're thinking about learning Docker, Linux, or cloud infrastructure, here's my advice.
Don't start by memorizing commands.
Start by asking questions.
The commands will eventually become muscle memory.
Understanding will stay with you much longer.
If this article encouraged you to start building your own VPS, then it has already done its job.
See you in Part 2.
Top comments (3)
"I wouldn't run a command I didn't understand" — I want to be honest and say I lived by the opposite rule for a year (run it, watch what breaks, understand later), and it mostly worked... except the one time it mattered most. My first real server was the office storage box at the hospital where I work, and the week I migrated my first tool onto it, I was so afraid of the admin account that I double- and triple-checked I'd logged out every single evening. Infrastructure is exactly where your discipline beats my recklessness: app mistakes embarrass you, infra mistakes erase things.
Your image-vs-container line ("a blueprint / a running instance of that blueprint") is the cleanest one-sentence version of that distinction I've seen — that one usually takes people a whole confused week. Looking forward to part 2. Domain and reverse proxy next?
Yes.
I explored docker in depth, moved forward to working with domains and learning about reverse proxy with Nginx Proxy Manager.
That's exactly the natural next staircase — container first, then "wait, how do people actually reach this thing," then reverse proxy. Nginx Proxy Manager was a good call for that stage; seeing routes and certificates in a UI made the whole concept click for me long before the config files did.
One small thing I learned the slow way: once the proxy is in front, write down somewhere which port each container actually listens on internally. Six months later, "why is this 502-ing" is almost always that map living only in your head. Looking forward to Part 2 — the domain + proxy episode is usually where the war stories start.