My Journey in Homelabbing
A look at how I fell into homelabbing, what I’m running now, what I’ve broken along the way, and how self-hosting has probably taught me more about real-world IT than I originally expected.
I definitely did not get into homelabbing because I had some perfect plan or enterprise-grade network diagram sitting around lol. I got into it because I like messing with technology, breaking things, fixing them, and figuring out how stuff actually works when you’re the one responsible for keeping it alive.
My first real experience with anything close to homelabbing was Jellyfin back around 2019. At the time I didn’t even really understand what “self-hosting” meant. I just thought it was really cool that you could host your own media server instead of relying on some outside service.
Then I got my first Raspberry Pi for my 3D printers so I could setup OctoPrint. That was another one of those moments where I was like, “Wait… I can just host this myself?”
And thats pretty much where the rabbit hole started.
Later on my uncle introduced me more seriously to the whole idea of homelabbing. At the time I barely even knew what that meant. I just knew I liked the idea of having my own servers and systems I could mess around with without worrying about breaking anything important.
After that it kind of blew up exponentially.
At first most of my homelab was just personal projects and random stuff that made my life easier. I wanted my own media server, 3D printer controller, cloud storage, dashboards, and basically whatever cool project I happened to find that week.
But once I started getting more serious about IT and working on certifications, I realized there was a much bigger benefit to all of it.
Studying for certifications is useful, but there’s a BIG difference between reading about DNS, Linux, firewalls, backups, virtualization, or VPNs and actually having something break at 1AM because you changed the wrong setting.
Or updating something because surely nothing will go wrong…
And then it goes wrong.
Thats when the homelab started becoming more than just a hobby for me. It basically became my practice environment.
Over time what started as a couple experiments turned into physical servers, Raspberry Pis, VPS servers, Docker containers, TrueNAS storage, Proxmox, UniFi networking, DNS filtering, reverse proxies, VPNs, monitoring, and a bunch of services that are part useful, part “ok this is really cool,” and part “I wonder if I can make this work.”
What My Homelab Looks Like Now (General Overview)
(Rough, not-fully-updated layout of what I’m running. I used homelable to generate this graph.)
Right now my homelab is spread across around 15 hosts.
Some are physical machines, some are Raspberry Pis, some are VMs, and some are VPS servers out on the internet. Most of my services run in Docker, with Docker Compose and Portainer helping me keep everything at least somewhat manageable.
I say somewhat because the lab is always changing.
I’ll clean something up, add three more services, realize my documentation is outdated, break something else, fix that, then somehow end up with another project.
Thats basically the cycle lol.
The main pieces right now are:
- TrueNAS for storage and backups
- Proxmox for virtualization
- Raspberry Pis for smaller dedicated services
- VPS servers for public-facing stuff
- UniFi for my home network
- Docker for most of my applications
- Reverse proxies and tunnels for accessing services
- DNS filtering and VPN access
- Monitoring and dashboards
- Security experiments and logging practice
Written out like that it sounds pretty organized.
In reality its been a lot of trial and error and asking “why is this not resolving?”
TrueNAS and Storage
One of the main systems in the lab is my TrueNAS server.
It’s running a 12th Gen Intel Core i5-12400 with 16GB of DDR5 RAM. Storage wise I have five hard drives, with four of them making up my main RAIDZ1 pool and another drive used for backups.
I also have two SSDs. One is being used for apps and I may use the other for cache later after I max out the RAM.
From what I’ve learned, with ZFS its usually better to give it more RAM before immediately throwing cache drives at it. So thats one of those things where I’m trying to actually understand what I’m doing instead of adding parts because they sound cool.
Which is VERY tempting.
My main pool gives me around 31TB usable right now. I use it for file storage, media, photos, and Time Machine backups for my Macs.
Important data also gets replicated to another drive, and eventually I want to build another TrueNAS system at a family member’s house so I can have a proper offsite backup.
That is one of the BIGGEST lessons storage has taught me: having a lot of space is not the same as having a PROPER backup plan (Cough cough.. raid is not backup ahem..).
Docker Is Where Most of the Lab Lives
A huge chunk of my homelab runs on Docker.
At this point I have 40+ services spread across different systems. Some are genuinely useful, some are experiments, and some are literally just things I found and thought “this looks cool.”
I love Docker!
There is definitely a learning curve when you first start messing with it, but once you get used to it its so worth it. Everything gets its own container, deployments are easier to manage, and its sooo much cleaner than installing a bunch of stuff directly onto the host.
Right now I run things like Jellyfin, Immich, AdGuard Home, WireGuard, Nginx Proxy Manager, Traefik, Pangolin, CrowdSec, Uptime Kuma, FreePBX, Home Assistant, Homebridge, Frigate, ADS-B tracking with tar1090, OctoPrint, dashboards, and a whole bunch of smaller tools.
Docker has taught me a TON because containers are simple…
Until they aren’t.
Then suddenly you’re dealing with ports, volumes, permissions, environment variables, container networking, DNS, reverse proxies, updates, logs, and whatever other thing decides to break that day.
Sometimes the problem is obvious!
Other times you stare at it for 45 minutes just to realize you spelled one environment variable wrong…
That pain is useful though.
It teaches you how to actually troubleshoot instead of just randomly changing settings until something magically starts working again.
AI has honestly been really useful for this too.
Not as a magic “fix my server” button, but more like a second set of eyes. If I paste in an error message, Docker logs, or explain everything I’ve already checked, it can usually help point me toward the next thing I should look at.
Sometimes its something stupid like a bad path or a port conflict. Other times it just helps me organize what I should check next.
I definitely don’t blindly trust it though.
AI can be VERY confidently wrong.
But for debugging logs, explaining unfamiliar errors, giving me commands to verify things, or helping me understand why something broke instead of just copying a fix, its been extremely useful.
Networking, DNS, and Remote Access
My network runs on UniFi gear. I am still learning how to use it better, and I want to eventually get deeper into VLANs and segmentation. I have not fully built that out yet because I want more UniFi gear first, but it is definitely in the plan!
DNS has been one of the biggest learning areas for me. I run AdGuard Home for DNS filtering, and once you start messing with DNS, you realize how much depends on it. If DNS is broken, everything feels broken. Just like Jeff Geerling says “It Was DNS…” and theres a reason for that saying lol.
For remote access I’ve used WireGuard/wg-easy, Cloudflare DDNS, reverse proxies, and Pangolin/Newt tunnels. I’ve also messed around with Nginx Proxy Manager and Traefik.
Working with all of that forced me to actually understand how traffic gets from something like a domain name all the way down to the service running in a container.
DNS records, SSL, ports, proxy hosts, firewall rules…
It all starts connecting together.
Reverse proxies were one of those things that sounded really confusing when I first heard about them, but once it clicked I was like “ohhhhhh.” And once you understand them they unlock a lot.
Security and Hardening
Security is one of the parts I want to keep improving. Because there’s no such thing as “fully secure” only more secure than before.
On my Linux servers and VPS systems, I use non-root users, SSH keys, firewall rules, automatic updates, and basic hardening where I can. I also have scripts that alert me when the server catches unique behavior.
CrowdSec is running on my Pangolin server right now, and I want to expand it to more systems later. I also run an OpenCanary honeypot on a Raspberry Pi, mostly as a way to learn about alerts and see what suspicious activity can look like.
One thing I learned the hard way is that Docker and UFW can be weird together. Docker can interact with firewall rules in ways that are not always obvious, so you cannot just assume UFW is blocking what you think it is blocking. That sent me down another rabbit hole of learning how Docker networking actually works.
My next big security goal is better logging and alerting. Logs are GOLD…. If something breaks or something weird happens, logs are what tell the story. Right now, I want to get better at centralizing logs instead of bouncing between machines trying to figure out what happened.
I also want to build an isolated pentesting lab.
The idea is to spin up intentionally vulnerable Docker containers inside of a VM, then use Kali or Parrot to practice attacking them in a safe environment.
Nothing public.
Nothing sketchy.
Just a contained place where I can break stuff and learn.
Proxmox, Clustering, and Future Plans
Proxmox is another part of the lab I want to expand.
I already use it for VMs, but I want to setup a Proxmox cluster soon. That should give me a better understanding of clustering, VM management, and how multiple hypervisors can work together.
I also really want to mess with Kubernetes! I’m not gonna sit here and pretend I understand Kubernetes deeply yet because I absolutely do not.
That thing still feels like magic half the time.
But I want to understand the basics and see why people use it for container orchestration instead of just reading about it.
Some of my next goals are:
- Build the Proxmox cluster
- Learn Kubernetes basics
- Clean up my Docker Compose files
- Setup Gitea for versioning my configs
- Improve backups for service data
- Centralize logs and alerts
- Build out VLANs once I have the network gear
- Expand CrowdSec and security monitoring
- Build the isolated vulnerable-container lab
The lab is definitely not finished.
But I don’t think it ever will be lol :)
Why It Matters
Probably the biggest thing homelabbing has taught me is how everything connects together.
A service might look simple on the surface, but behind it you could have Linux permissions, Docker networking, DNS records, SSL certificates, firewall rules, storage paths, backups, and user authentication all working together.
If one tiny piece is wrong, suddenly the entire thing feels broken.
And thats helped me develop a much better troubleshooting mindset.
What changed?
Check the logs.
Verify DNS.
Check the port…
Check the container…
Check permissions…
Try not to panic lol
Then once you finally fix it, DOCUMENT IT because you’re absolutely going to forget what you did six months from now.
I still have a lottt to learn, but thats honestly why I like homelabbing so much.
There is always another system to understand, another issue to troubleshoot, another weird technology I’ve never heard of, or another project that starts with:
“I wonder if I can make this work.”
One of my favorite sayings is:
A jack of all trades is a master of none, but oftentimes better than a master of one.
And honestly I think that fits my homelab pretty well.
I’m not trying to claim I’m an expert in every single thing I run. Half of this stuff I originally setup because I thought it looked cool and wanted to figure out how it worked.
I’m just building stuff, breaking stuff, fixing it, documenting what I learned, and moving onto the next project.
And honestly…
Thats the fun part.