It all started with Friends.
Not Docker. Not Kubernetes. Not some grand ambition to build a miniature data center in my apartment. I just wanted to watch Friends.
Back in India, streaming was relatively straightforward. Netflix had most of the shows I enjoyed — Friends, The Office, Brooklyn Nine-Nine — all in one place, at a reasonable price. Then I moved to the United States. Suddenly, my favorite shows were scattered across different streaming platforms. One show was on this service, another on that one, and each wanted its own monthly subscription. I found the whole thing rather annoying.
Somewhere along the way, I stumbled upon Jellyfin, an open-source media server that lets you organize and stream your own media library. That sounded interesting. At the time, I had an M1 MacBook Pro and a couple of 1 TB external hard drives gathering dust. I already had the hardware, so why not put it to use?
I installed Jellyfin, connected the drives, and started experimenting. I didn’t know it then, but I’d just taken my first step down a very deep rabbit hole.
My Laptop Wasn’t Really a Laptop Anymore
For a while, everything worked surprisingly well. The MacBook handled Jellyfin without much trouble, and those external hard drives finally had something useful to do.
There was just one problem. My laptop had essentially stopped being a laptop. It needed to stay plugged in, powered on, and connected to the drives whenever I wanted the media server available. Want to take the laptop somewhere? Better think about what’s running on it first. Not exactly ideal.
Then, one day, Amazon had a sale on Mini PCs. I started looking into them and realized that a small, relatively inexpensive computer could do everything I needed without taking over my personal laptop. Something I could plug in, tuck away, and largely forget about.
So I bought one. And just like that, I had a dedicated little server running at home. My MacBook was finally free to be a laptop again.
I thought I’d solved my problem. Technically, I had. The trouble was that I had also discovered something new to be curious about.
Wait, I Can Host That Too?
Once I had a dedicated server, I started looking at the other services I used every day. Google Photos. Google Drive. Apple Music. Streaming platforms. Individually, these services were convenient. But together, they represented quite a collection of subscriptions, all for things that had become part of my everyday digital life.
And now that I had a server sitting at home, a question kept coming back to me.
What else could I run myself?
Turns out, quite a lot. One of the first things that caught my attention was Immich, a self-hosted photo and video management platform. This one was particularly interesting to me.
Photos are personal. Really personal. They’re memories of people, places, and moments that you can’t simply recreate if something goes wrong. And with AI becoming increasingly integrated into cloud services, I wasn’t particularly comfortable leaving questions about how my personal photos might be processed or used entirely in someone else’s hands.
I wanted more control over my data. Immich seemed like a great way to get that.
But then I had another thought. What if I accidentally lose all my photos? And suddenly, things got a little more serious.
With Ownership Comes Responsibility
There’s a pretty big difference between losing access to a television show and losing years of family photographs. One is an inconvenience. The other could be heartbreaking.
If I was going to trust my own infrastructure with something that important, I needed to make sure I could protect it properly. That meant learning more about storage, redundancy, and backups.
A traditional NAS seemed like the obvious choice, but I already had a perfectly capable computer running my applications. Buying another computer just to manage disks didn’t seem necessary. So I went with a DAS — Direct Attached Storage. It was a more affordable way to expand my storage without replacing the server I already had.
Then came MergerFS and SnapRAID. MergerFS let me combine multiple drives into a single logical storage pool, while SnapRAID gave me parity protection against certain disk failures. Wonderful. Except there was another lesson waiting for me.
Redundancy is not backup.
Parity might help me recover from a failed drive, but it wouldn’t necessarily save me from accidental deletion, corruption, or losing the entire setup. So I started looking into the 3-2-1 backup strategy: three copies of important data, across two types of storage, with one copy kept off-site. That’s how Backblaze B2 entered the picture.
Yes, I started self-hosting partly to depend less on cloud services, and now I was paying for cloud storage to back up my homelab. The irony wasn’t lost on me.
But I was beginning to understand something important. Self-hosting doesn’t have to mean avoiding the cloud entirely. Sometimes, using a cloud service is exactly the right architectural decision. The point was having the freedom to decide what made sense for me.
One Thing Led to Another
By this point, my little Jellyfin experiment had already grown into something much bigger. And it wasn’t showing any signs of slowing down. Even in the early days, I’d grown tired of remembering IP addresses and port numbers. Traefik made accessing my applications through proper domain names and HTTPS much more pleasant.
Then I wanted to access my services when I wasn’t home. Tailscale worked wonderfully for that, until I encountered a rather specific problem. I wanted to watch something on my Tesla’s screen while the car was charging. Unfortunately, installing Tailscale on a Tesla isn’t exactly an option. That sent me exploring other ways of accessing my services remotely, eventually bringing Cloudflare into the mix.
Of course, making services accessible outside my home raised another set of questions. Who should be allowed in? How do I protect publicly accessible applications? How do I know when something suspicious is happening? That’s where tools like Keycloak and CrowdSec started becoming useful.
Then family members wanted access to some of my services, which made user management another interesting problem to solve. I started thinking about documents, too. If I was taking control of my photos, why not explore self-hosting important documents instead of relying entirely on third-party storage?
And once I had all these things running, I wanted to know what was happening behind the scenes. How much memory was everything consuming? Was the server healthy? What did network traffic look like? Enter Grafana, Prometheus, and Loki. Then there was TeslaMate for tracking my car’s statistics, DNS-based ad blocking, and a growing list of other projects I wanted to try.
Every time I thought the setup was complete, another question appeared. And every question seemed to lead to another tool, another experiment, or another weekend spent figuring something out.
At some point, I stopped thinking of it as a media server. It had become my homelab.
So, Why Do I Still Do It?
Here’s the funny thing. I work as a Cloud & Infrastructure Architect. I spend a good part of my professional life designing infrastructure and working with cloud technologies. And then I come home and voluntarily manage more infrastructure. You’d think I’d have had enough of it by the end of the workday.
But there’s something different about doing it yourself. Cloud platforms are incredible at abstracting away complexity. Need a database? There’s a managed service for that. Need object storage, monitoring, authentication, or load balancing? Someone has probably already built and packaged a solution for you. And that’s a good thing. But sometimes, those abstractions also mean you don’t get to experience the underlying details.
Why does a particular system work the way it does? What happens when a component fails? What does it take to make something reliable? Could I solve the same problem differently? My homelab gives me a place to explore those questions. At work, I might design the architecture of a system. At home, I’m also the person installing it, configuring it, maintaining it, and figuring out why it suddenly stopped working.
There’s no support team to escalate to. Well, technically there is one.
It’s me.
And strangely enough, I enjoy that. I’ve always liked taking things apart, understanding how they work, putting them back together, and occasionally trying to make them work differently.
Sometimes an experiment goes exactly as planned. Other times, I spend hours troubleshooting something, only to discover that the entire problem was a tiny configuration mistake. Both experiences teach me something. And those lessons carry over into my professional work. Understanding the operational details behind the infrastructure I design helps me appreciate the trade-offs that managed services are designed to address.
But beyond the professional benefits, there’s something genuinely satisfying about building something yourself. My homelab isn’t just a collection of containers running on a computer. It’s something I built, something I maintain, and something that has slowly become part of my everyday life. It stores memories. It runs applications my family can use. It gives me a place to experiment with technologies I find interesting. And perhaps most importantly, it’s mine to understand, change, break, and rebuild.
Is self-hosting always cheaper than using cloud services? Not necessarily. Is it easier? Definitely not. There are days when a simple subscription would be considerably less trouble.
But I didn’t start doing this because I wanted another responsibility. I started because I was curious. And somewhere along the way, I discovered that I genuinely enjoy the process of figuring things out.
The cloud isn’t going anywhere, and neither is my homelab. They serve different purposes, and I’ve learned a great deal from both. For now, there’s always another project to try, another problem to solve, or another part of the system I don’t quite understand yet. And I like it that way.
All because I wanted to watch Friends.
