A home server is rarely built according to plan. Usually everything starts with one container to “try,” after six months a box runs fifteen services, half of which stick out, there are no backups, and updating is scary because it’s unclear what will break. Familiar — which means you’ve just skipped a couple of steps.
Below is a map of six levels of maturity for home infrastructure. This isn’t a rating of who’s cooler: most people are fine living at levels 2–3 and never go higher. The value of the map is elsewhere — it shows what makes sense to do next, and warns about the common mistake at each level. Don’t jump levels: beautiful monitoring with no backups is decorating a house without a foundation.
Level 0. One box, one service
What happens. You have hardware — an old laptop, a mini PC, a Raspberry Pi, or a VPS. Docker is installed on it, and the first service is running: most often a media library, a torrent client, or notes. Access is via a local IP with a port, like 192.168.1.50:8096.
What this gives you. The main thing at this level is to understand that a server isn’t scary. You learn to read docker logs, restart a container, and figure out where it stores its data.
Typical mistake. Launching everything with long docker run commands from your terminal history. In a month you won’t remember which flags you used to start the service, and you won’t be able to reproduce it. Cure it now: document every service in a docker-compose.yml, even if there’s only one. The file is documentation that doesn’t lie.
Move on if you have more than two services and you’re starting to confuse ports.
Level 1. Names instead of ports
What happens. A reverse proxy appears — Nginx Proxy Manager for those who like a GUI, Caddy for those who prefer three lines of config, Traefik for those who love automation with Docker labels. Services get human-readable addresses and HTTPS.
What this gives you. Instead of a zoo of ports — jellyfin.dom.local and photos.dom.local. Certificates are issued automatically. A single entry point appears, through which authentication and logs can be attached later.
The key point of this level is that services stop publishing ports to the outside. In the Docker stack they live in a common user network, talk to each other by container names, and only the proxy publishes ports. Network mechanics are covered in a separate guide (link).
Typical mistake. Expose ports to the outside “just for testing” and leave it that way. Another variant is to immediately open the entire server to the Internet via port forwarding on the router, without knowing who might reach it. If you need external access, it’s better to move to level 4 and access via VPN rather than exposing the admin panel publicly.
Move on if you’ve started to value data you’d hate to lose: family photos, documents, password database.
Level 2. Data you don’t mind losing
This is the dullest but most important stage. It’s the one most people skip — because backups don’t deliver anything pleasant here and now.
What happens. You keep two things in your head: RAID is not a backup, and a copy on the same server — even more so. RAID protects against a disk failure, but not against rm -rf, ransomware, a blown power supply, or a flooded room. A working architecture is described by the 3-2-1 rule: three copies of data, on two different media, one of which is offsite.
Practically this means automatic backups of important directories and database dumps to a second drive plus synchronization to remote storage. Tools are chosen to taste: restic, borg, rclone, Duplicati — what matters is not the name, but that the job runs on a schedule without your participation.
Separate topic — databases. Copying files of a live PostgreSQL is a surefire way to get an inconsistent backup that looks fine until you try to restore. For databases, do a logical dump (pg_dump) or a physical backup with a WAL archive. For PostgreSQL internals, including WAL and autovacuum, there is an in-depth analysis (link).
Typical mistake. Set up backups and never test restores. An untested backup is not a backup, it’s a hope. Quarter-yearly, restore the archive to a separate folder and make sure the data can be read.
Move on if you’ve started to hear about a home service going down rather than the system itself.
Level 3. Observability
What happens. The server starts telling you what’s going on. The starter kit is minimal: Uptime Kuma checks if services are alive and sends Telegram alerts when something goes down. This alone is enough to cover 80% of needs.
For deeper needs — add metrics: Prometheus plus Grafana, or VictoriaMetrics as a more resource-friendly alternative. Then you’ll see not only if something is up or down, but trends: how disk space is being used, when the CPU gets hot, which container leaks memory.
What this gives you. A move from reactive to predictable operation. A disk that will fill up in a week is visible in advance, not at the moment the service stops writing data.
Typical mistake. Build pretty dashboards and not configure a single alert. A graph that no one watches is useless; an alert that disk space is running out is lifesaving. And the opposite: alert on everything, get a flood of noise, and ignore it after a week.Alerts should be reserved for what you can actually get up to fix.
Move on if you have many services, external access is needed, and you worry about who can open the admin panel.
Level 4. Access and security
What happens. Instead of port-forwarding to the outside — VPN to get home: WireGuard if you want to control everything yourself, or a mesh solution like Tailscale (or self-hosted Headscale to avoid depending on a third party). Outside you can’t see anything, but you can enter the home network as if from inside.
On top of this comes a single entry: an identity provider like Authentik or equivalent provides SSO for services with weak or no authentication. At the same time, password hygiene is improved — Vaultwarden, and two-factor authentication is enabled where available.
This level also covers update discipline. Automatic container updates sound convenient until a major release breaks your database schema. A reasonable compromise: update on a schedule and manually after reading release notes, and have a fresh backup before updating — level 2 should already be working.
Typical mistake. Assuming that since a service is “inside the home network,” it doesn’t need protection. Home networks also include IoT devices with questionable firmware, guest phones, and smart bulbs. Segmentation (a separate VLAN for IoT) at this level stops being paranoia.
Move on if you’ve caught yourself thinking the home services have become infrastructure, a thing that makes life easier but actually gets in the way.
Level 5. Resilience
The last level isn’t needed by everyone, and that’s fine.
What happens. The infrastructure stops depending on a single box and on your memory. A UPS appears — the most underappreciated upgrade for a home lab, because a sudden power outage hits file systems and databases harder than any software failure. A second node appears: either a cluster (K3s or Docker Swarm), or simply a spare machine onto which everything can be re-created from backups in an hour.
Configuration moves to Git and is described as code — Ansible, Nix, docker-compose in a repository. The point isn’t fashion of IaC, but reproducibility: a server you can rebuild from the repository and backups ceases to be indispensable.
Typical mistake. Building a cluster for the sake of a cluster. Running Kubernetes at home is a great learning platform, but as a way to increase reliability it often adds more points of failure than it removes. If the goal is “to prevent downtime,” UPS, backups, and a second disk will provide more than an orchestrator.
How to use this
Determine at what level you are now, honestly — by your weak point, not by your strongest. If you have Grafana with twenty dashboards, but the last backup has never been checked, your real level is two, and the next step is obvious.
Next — one step at a time, until the state «works by itself and doesn’t require attention». Infrastructure that needs constant monitoring is not a hobby, but a second job, and that is exactly why most home servers die: not from technical problems, but from the owner’s fatigue.
An overview of concrete tools by category, if you’re still choosing a stack, — in a separate thread.
Sources
- Docker documentation: networks and best practices
- Awesome-Selfhosted — catalog of self-hosted software by category
- The 2026 Homelab Stack (elest.io) — what people are actually running
What level is your home lab at and which step was the hardest for you? And honestly: when did you last check that the backup actually deploys?