My Homelab Was Never About Watching Movies

TL;DR: I wanted somewhere to watch movies. I accidentally learned networking, Linux, virtualization, containers, storage, backups, and now I spend more time maintaining servers than watching them.

How a Jellyfin server accidentally taught me networking, Linux, virtualization, and why "it works" isn't the same as understanding it.

Concept: Homelabs • Linux • Networking • Virtualization Published: July 2026

If you asked me a year ago why I wanted a home server, my answer would've been embarrassingly simple.

I wanted somewhere to watch movies.

Not distributed systems. Not virtualization. Definitely not networking.

I was just tired of my media library disappearing every time a streaming service decided to remove something.

So I did what I knew at the time.

I installed Docker Desktop on Windows, pulled the Jellyfin image, mounted a folder, forwarded a few ports on my router, and...

it worked.

At least, for a while.

(Screenshot: My very first Docker Desktop setup on Windows.)

Docker on Windows was enough... until it wasn't.

Jellyfin became Sonarr.

Sonarr became Radarr.

Before long I'd added Prowlarr, qBittorrent, Frigate, Home Assistant, and a growing collection of side projects.

Somewhere along the way, my "media server" quietly became the computer that ran everything.

The problem wasn't Docker.

Docker was doing exactly what it was supposed to do.

The problem was that I had no boundaries.

Everything shared the same machine, the same operating system, and the same network. If something broke, I wasn't always sure what I'd broken—or what fixing it might accidentally affect next.

I could make things work.

I just couldn't explain why they worked.

Windows stopped being the problem. Understanding became the problem.

At first I blamed Windows.

Surely Linux would solve everything.

So I installed Linux.

Things improved.

But after a while I realized I'd only changed operating systems.

I hadn't changed how I thought about infrastructure.

Every new application was still "just another container."

Every deployment still lived together.

Every mistake still had the potential to affect everything else.

Changing operating systems didn't magically make me understand systems.

It just gave me better tools to learn them.

Port forwarding taught me my first networking lesson

Like most people getting into self-hosting, my first solution to remote access was simple.

Open a port.

Forward it.

Access it from anywhere.

Problem solved.

Except... it wasn't.

Every new service meant another exposed port.

Every tutorial had different advice.

Some said, "It's fine."

Others said, "Never expose anything."

I followed guides without really understanding the tradeoffs.

Eventually I realized something that now feels obvious:

Just because something is reachable doesn't mean it should be publicly reachable.

That realization pushed me toward Tailscale.

Instead of exposing my home network to the internet, I created a private network where only my own devices could reach my services.

The first time I opened Jellyfin from outside my house without forwarding a single port genuinely felt like magic.

More importantly, it forced me to understand why it worked.

Later, I started experimenting with Cloudflare Tunnels for services that actually made sense to expose publicly, separating private infrastructure from public applications instead of treating them the same.

Then I discovered Proxmox

This is where the rabbit hole really began.

Originally, I thought Proxmox was just...

Linux with a nicer UI.

It took about a week to realize how wrong that assumption was.

Suddenly I wasn't thinking in terms of applications anymore.

I was thinking about isolation.

Should this run inside a virtual machine?

Would an LXC be enough?

Does it actually need its own kernel?

How much memory should I allocate?

Can I snapshot this before experimenting?

What happens if one service completely fails?

Those questions completely changed how I approached self-hosting.

Proxmox wasn't interesting because it let me run more services.

It was interesting because it forced me to think about where those services belonged.

(Screenshot: Current Proxmox dashboard.)

My server stopped being a server

It became a lab.

Some weekends I'd spend more time rebuilding things than actually using them.

I migrated services.

Broke networking.

Restored backups.

Moved storage.

Experimented with bind mounts.

Learned the hard way why Linux permissions matter.

Accidentally deleted things.

Recovered them.

Then somehow managed to break them again.

Looking back, almost every mistake taught me something another tutorial never could.

The biggest lesson wasn't technical

The biggest lesson was realizing that infrastructure isn't invisible.

Good infrastructure changes the questions you ask.

I stopped asking:

"How do I install this?"

and started asking:

"Where should this run?"

Instead of asking:

"How do I expose this service?"

I started asking:

"Should this service even be exposed?"

Instead of treating every application as another Docker container, I started thinking about isolation, recovery, reproducibility, backups, and operational simplicity.

That shift mattered far more than learning another command.

Looking back

It's funny.

I started all of this because I wanted somewhere to watch movies.

Now I spend far more time reading about Linux namespaces, virtualization, networking, storage, containers, and distributed systems than I do actually watching anything on Jellyfin.

The media server was never really the destination.

It was the excuse.

Every new service introduced another question.

Every mistake uncovered another layer of how computers actually work.

I still don't consider myself an expert.

There's an endless amount left to learn.

But somewhere between opening my first router port and rebuilding my infrastructure inside Proxmox, I stopped treating servers as appliances.

I started treating them as systems worth understanding.

And that's probably the most valuable thing this homelab ever gave me.