Build a homelab on Debian

level:Beginner

ℹ️ How to read this series — a mix of read-along concept parts and hands-on parts where you build the box. Each part says which at the top.

You have a spare machine — an old laptop, a mini PC, a tower that stopped being your daily driver — and a vague sense that it could be doing something useful. This series turns that machine into a homelab: a small, always-on server you own, running on Debian, hosting the kind of things you would otherwise rent from someone else. It is written for someone who has used a computer comfortably but has never set up a server, and it is exact enough that the commands actually work. By the end you will have gone from a blank disk to a quietly humming little box that backs itself up and tells you when something is wrong.

What a homelab actually is

A homelab is a server (or a few) that you run at home for your own use and your own learning. The "lab" half is the important part: nobody is paying you for uptime, so you are free to break things, rebuild them, and understand them in a way you never can when the box belongs to an employer. The "home" half means it lives on your own network, on hardware you can touch, with no monthly cloud bill ticking in the background.

People reach for a homelab for different reasons, and any one of them is enough. Some want to self-host — to run their own file sync, photo library, media server, password manager, or notes app instead of renting those services. Some want a safe place to learn the same Linux, networking, Docker, and Kubernetes skills that show up in real infrastructure jobs. Some just want control over their own data. The skills overlap heavily with professional platform and DevOps work, which is part of why a homelab is such a good teacher: the concepts you practise on a mini PC in a closet are the same ones running data centres.

What "self-hosting" means

Self-hosting is running a piece of software on a machine you control rather than using someone else's hosted version of it. Instead of paying for a cloud notes service, you run the notes server yourself and your notes live on your disk. The trade is straightforward: you take on the work of keeping the machine healthy, and in exchange you get ownership of your data and a much deeper understanding of how the software actually works. This series is, end to end, a guided tour of doing exactly that — safely and in a sensible order.

flowchart LR
    A["Old laptop / mini PC<br/><i>otherwise idle hardware</i>"] --> B["Install Debian<br/><i>a stable base OS</i>"]
    B --> C["Run services<br/><i>files, media, notes, dashboards</i>"]
    C --> D["You own the data<br/><i>no monthly cloud bill</i>"]
    C --> E["You learn the skills<br/><i>Linux, Docker, networking</i>"]

A homelab takes idle hardware and turns it into both a useful service and a teacher.

Why Debian, in one line

There is a saying that fits this series well: Arch for the machine you sit at, Debian for the machine in the closet. If you have read Why Arch Linux, you know Arch is a brilliant choice for a desktop you tend to daily — newest software, total control, an engaged owner who reads the news before updating. A homelab server is the opposite kind of machine. You want it to sit in a closet and not demand attention: predictable, boring, supported for years, the same tomorrow as it is today. That is precisely what Debian's stable release is built to be. The next part, Why Debian for a homelab, makes the full case and shows where Debian sits in the distribution families — but the one-line version is that a closet server should be the least interesting computer you own.

💡 Tip If you only remember one thing from this series, remember the contrast: a rolling release like Arch is a great desktop and the wrong tool for an always-on server. For the closet, you want stability, not novelty.

The road ahead

The series is ordered on purpose. Each part assumes the one before it, and the difficulty climbs gently from "install an operating system" to "run a tiny Kubernetes cluster." You do not have to do all of it — many people stop happily after services and backups — but the path is built so that each step leaves you with a working machine, not a half-finished one.

flowchart TD
    A["1. Why Debian<br/><i>pick the right base</i>"] --> B["2. Install Debian<br/><i>blank disk to login prompt</i>"]
    B --> C["3. Harden it<br/><i>SSH keys, firewall, updates</i>"]
    C --> D["4. Docker and Compose<br/><i>run software in containers</i>"]
    D --> E["5. Reverse proxy and first service<br/><i>real URLs, HTTPS</i>"]
    E --> F["6. Storage and backups<br/><i>protect the data</i>"]
    F --> G["7. Monitoring<br/><i>know when it breaks</i>"]
    G --> H["8. From Docker to k3s<br/><i>a small Kubernetes cluster</i>"]

Each step leaves you with a working machine; the difficulty climbs gently from install to cluster.

Here is the full reading list:

Why Debian for a homelab — the case for a boring, stable base, and why a rolling release is the wrong tool for a closet server.
Installing Debian server — from a blank disk to a login prompt, the minimal-and-clean way.
Hardening a fresh Debian server — SSH keys, a firewall, automatic security updates, and the basics of not getting owned.
Docker and Compose on Debian — running software in containers so installs stay clean and repeatable. (New to the name? Where the name Docker comes from.)
Reverse proxy and your first self-hosted service — turning :8080 ports into real names with HTTPS.
Homelab storage and backups — where the data lives and how to get it back when something dies.
Monitoring your homelab — dashboards and alerts so the machine tells you when it is unhappy.
From Docker to k3s — graduating to a lightweight Kubernetes if you want to. (And yes, there is a reason it is called k8s.)

How to read it

If you are starting from nothing, read in order and do each step on real hardware as you go — the doing is where the learning happens. If you already run Linux and just want the homelab parts, skim parts one and two and slow down at hardening. If a term is unfamiliar, the cross-links lead to short explainers: what a daemon is, what SSH is, and so on.

ℹ️ Note You do not need expensive hardware to start. A ten-year-old laptop or a cheap second-hand mini PC is plenty for the first six parts. The point is to learn on something you do not mind breaking.

⚠️ Warning Do not start your homelab on a machine that holds the only copy of anything you care about. Part two wipes a disk. Use a spare machine, or back up first — part six covers backups properly, but until then, assume anything on the lab box can be lost.

Where this leads

A homelab is not the destination; it is the on-ramp. The same moves you practise here — a stable base, containers, a reverse proxy, backups, monitoring, and eventually a small cluster — are exactly how real infrastructure is run, just at a different scale. The final part hands off to a whole companion track: Kubernetes from scratch with k3s takes the Docker-Compose foundation you build here and teaches the cluster world hands-on — pods, deployments, services, ingress — on a real k3s cluster. And if you want to see where the path ends up, my own setup is documented on the /server page: the actual hardware, the actual services, and the actual stack this series quietly points toward. Start with one spare machine and part one, and you will recognise every piece of it by the end.

A short close

You do not need a rack, a budget, or permission to start a homelab. You need a spare machine, an evening, and a reason — owning your data, learning the skills, or just the satisfaction of running your own corner of the internet. Debian gives you a base that will not fight you, and this series gives you the order to build it in. Begin with Why Debian for a homelab, and meet me back here when your closet is humming.