It’s been a while since I wrote a blog post. Recently, I decided to get back into writing and document something I’ve been playing around with: setting up a small homelab environment on an Oracle Cloud Free Tier VPS.
As a software engineer, I’ve always been interested in what happens behind the scenes when an application moves from my laptop to an actual server. Things like networking, deployment, Linux, containers, firewalls, and DNS are all areas I’ve wanted to understand better through actual hands-on experience rather than just reading about them.
The fact that I could do all of this on a free VPS made it even better.
Why I Started This Experiment
I initially set up an Oracle Cloud Free Tier VPS running Ubuntu with:
1 GB RAM
1 vCPU
Ubuntu Linux
A public IP address
I wasn't planning to host anything serious on it. The main goal was simply to use it as a small playground where I could experiment with infrastructure and improve my Linux and system administration skills.
Interestingly, the last time I regularly worked with a VPS was probably around seven years ago.
Back then, a few friends and I used to rent servers and set up Call of Duty 4 multiplayer servers. We'd spend hours messing around with the server configuration and, of course, playing on it afterwards.
Things have changed quite a bit since then.
These days, I'm much more interested in software engineering, DevOps, infrastructure, and homelabbing. So I thought it would be fun to take a free VPS and see how much I could actually do with it.
First Challenge: K3s on 1 GB of RAM
One of the first things I wanted to try was K3s, the lightweight Kubernetes distribution.
I wanted to get a basic Kubernetes environment running and use it to experiment with container orchestration.
That plan didn't last very long.
After installing K3s and starting the server, I noticed the memory usage climbing pretty quickly. With only 1 GB of RAM, there wasn't much room left for anything else.
Once I started thinking about running additional services alongside K3s, it became clear that this particular VPS wasn't going to be a great Kubernetes playground.
So I eventually stopped the K3s server.
It wasn't exactly the result I was hoping for, but it was still a useful experiment. One thing I've learned from working with infrastructure is that resource requirements matter a lot more once you're actually running the software yourself.
Something can be described as "lightweight," but that doesn't necessarily mean it'll be comfortable on a 1 GB machine.
Docker, Nginx and Firewall Configuration
After moving away from K3s, I started focusing on things that were more realistic for the resources available.
I managed to get several things running on the VPS, including:
Docker containers
Nginx
Ubuntu's firewall
iptables
A web application
This was probably the part of the experiment I enjoyed the most.
Instead of just following a tutorial and copying commands, I wanted to understand what was actually happening.
For example, I spent quite a bit of time looking at firewall rules, how packets are filtered, and how iptables fits into Linux networking.
I also used ChatGPT quite a lot during this process, but mostly as a learning assistant. Rather than asking it to give me a list of commands and blindly running them, I'd ask things like "What does this rule actually do?" or "Why is this port being blocked?"
That made a big difference.
The goal wasn't just to get the server working. I wanted to understand why it was working.
Deploying a Real Application
Once I had the basic infrastructure working, I decided to deploy something real.
I used a web application I had previously developed called Ceylon Tour Planner.
The application was containerized with Docker and deployed to the VPS.
This gave me a nice little environment to experiment with the complete deployment flow:
Application
│
▼
Docker
│
▼
VPS
│
▼
Nginx
│
▼
Public Internet
It's a fairly simple architecture, but setting it up yourself makes the relationship between all these components much clearer.
You start to see how the application, container, web server, networking, and public IP all fit together instead of treating them as completely separate concepts.
Connecting a Domain to the VPS
After getting the application running, the next step was connecting it to a domain.
I already had a domain registered through Namecheap, so I went into the DNS settings and created an A record pointing the domain to the VPS's public IP address.
The basic flow looked like this:
User
│
▼
ceylontourplanner.com
│
▼
DNS A Record
│
▼
VPS Public IP
│
▼
Nginx
│
▼
Docker Container
│
▼
Web Application
This was another good opportunity to learn something by actually doing it.
I spent some time looking into the differences between A records, CNAME records, the www hostname, and the @ host used for the root domain.
An A record maps a hostname to an IPv4 address, while a CNAME essentially creates an alias to another hostname.
These aren't particularly complicated concepts, but configuring them yourself and seeing the changes take effect on a real server makes them much easier to understand.
The 1 GB RAM Problem
The biggest limitation of this VPS is, unsurprisingly, the 1 GB of RAM.
You have to be quite careful about what you run.
A couple of containers might be fine, but once you start adding more services, memory disappears surprisingly quickly.
At one point, I decided to configure swap memory to give the server a little more breathing room.
What Is Swap?
In simple terms, swap is disk space that Linux can use when physical RAM starts running low.
When the system needs more memory, Linux can move less frequently used memory pages from RAM to the swap area on disk.
The important thing to remember is that swap is much slower than actual RAM. It isn't a replacement for having more memory.
However, it can be useful when you have a small amount of RAM and occasionally experience memory spikes. It can give the system some additional breathing room instead of immediately running out of memory.
After configuring swap, the VPS felt noticeably more comfortable with the workloads I was running.
It didn't magically turn a 1 GB VPS into a powerful server, but it definitely helped.
What I Learned
For such a small project, I actually ended up learning quite a lot.
I got hands-on experience with:
Linux server administration
Docker
Nginx
DNS configuration
A and CNAME records
Linux firewall configuration
iptables
Public IP networking
Swap memory
Containerized application deployment
VPS resource management
K3s and Kubernetes resource requirements
More importantly, I started to understand how these pieces fit together.
There's a big difference between knowing what an A record is and actually configuring one.
The same goes for firewall rules. You can read about iptables for hours, but troubleshooting why a connection isn't reaching your application teaches you something completely different.
That's probably the biggest benefit I got from this experiment.
Final Thoughts
Overall, I'm pretty happy with what I managed to do with the Oracle Cloud Free Tier VPS.
For a completely free environment, it's a really nice playground for experimenting with Linux, networking, Docker, Nginx, and basic infrastructure.
The 1 GB RAM is definitely the biggest limitation. Running heavier workloads isn't practical, and K3s becomes difficult once you start running other services alongside it.
But for lightweight applications, Docker containers, Nginx, networking experiments, and learning Linux administration, it's more than enough.
For me, the biggest value wasn't actually hosting the application.
It was the learning process.
Being able to break something, figure out why it broke, fix it, and understand what was happening underneath was exactly what I wanted from this experiment.
And I'm not finished yet.
At the moment, the domain is accessible over HTTP, but I haven't configured SSL yet.
So that's probably going to be the topic of my next experiment: setting up HTTPS and SSL for the domain using the VPS and Nginx.
Until then, happy homelabbing! 🚀 Visit my Blog Developer Daily
