Home lab
A repurposed desktop running Proxmox, with Docker containers serving Jellyfin, file storage, and dedicated game servers over cabling I ran myself.
- Proxmox
- Docker
- Linux
- Jellyfin
- Networking
- VPN
The most useful thing I have built is the server sitting in my house. It started as an old desktop I did not want to throw out, and turned into the place I actually learned Linux administration, virtualization, and networking — the parts of the field that a course covers in a slide and a home lab makes you live with.
The build
The host is a repurposed desktop tower. Reusing it meant working within what the case and the board would take rather than speccing a machine from scratch: checking what the power supply could actually support, what drives would physically fit, and keeping the airflow sane once it had more disks in it than it was designed for.
Proxmox and containers
It runs Proxmox as the hypervisor, so one physical machine can host several separate systems. That matters more in a lab than raw capacity does — I can stand up a VM, break it, and roll it back without taking anything else down with it, which is a much faster way to learn than reinstalling the host every time.
Services run in Docker containers rather than as a VM each. Containers start faster, use a fraction of the memory, and make a service something I can rebuild from its configuration instead of something I have to nurse along.
The setup has changed shape over time. It ran TrueNAS for storage at first, and moving off it was the point where I stopped copying tutorials and started making my own decisions about how the box should be laid out.
What it runs
- Jellyfin, serving my own media library to devices around the house. No subscription, no account, and it keeps working whether or not some company decides to keep the service running.
- File storage and backups. Shared storage for the machines in the house, and a backup target so anything important exists in more than one place.
- Dedicated game servers — Palworld, Minecraft, and Project Zomboid. Running them as dedicated instances means a world stays up whether or not my desktop is on, and everyone connects to the same persistent save instead of waiting on a host.
Game servers turned out to be the most demanding thing on the box. They hold a lot of state in memory, they do not tolerate being casually restarted, and Palworld in particular will take whatever RAM you give it — which made resource limits something I had to understand rather than something I could leave at the default.
Networking
I ran the cabling myself rather than relying on wireless — pulling the runs, terminating the ends, and testing each one. Doing it by hand is where you find out how much of networking is patience and labelling.
Remote access goes through a VPN, so the lab is reachable from outside the house without exposing services directly to the internet. That is the most valuable habit I picked up from running this: the default should be that nothing is reachable unless there is a specific reason for it to be. Game servers are the obvious temptation to cut that corner, and worth being deliberate about.
What it taught me
Coursework gives you the concepts. Running the hardware is what teaches you that drives fail, that a service which worked yesterday can stop for reasons that have nothing to do with the service, and that the fix is usually methodical elimination rather than a clever guess. Most of what I know about Linux and networking, I know because something here broke and I had to work out why.