Self-hosting, described at role level
Most homelab (privately operated servers and network equipment) write-ups are inventories: every hostname, every VLAN (logical network segment sharing physical network hardware), every gigabyte of RAM. That is satisfying rack-accounting and an unnecessary gift to anyone probing the setup (hi, scanners). This note tries the opposite: describing the infrastructure entirely by what each part is for. If a detail only matters when you know where something lives, it is not in here.
Why two environments
Everything runs in one of two places: a local environment at home, and a hosted one in a datacenter. The split is not redundancy theater - it follows from what each side is good at.
The hosted environment has the stable address and the fat pipe, so it owns everything the public internet is allowed to touch. The local environment has the storage and the physical access, so it owns data-heavy and private workloads. A site-to-site VPN (a private routed connection between two networks) gives them routed private connectivity - the services that are meant to talk across it can, everything else cannot, and nothing management-shaped is reachable from outside. Treating a tunnel as permission to flatten the network is lazy security. The tunnel is a road, not a trust badge (looking at you, flat LANs).
The roles
Five roles cover almost everything, and most exist on both sides:
- Ingress. Reverse proxies (a server that receives requests and forwards them to internal services) are the only doors. TLS terminates there, domains route there, and a service that is not behind one is not public.
- DNS. Internal name resolution runs in both environments, so the private network has real names instead of memorized addresses.
- Monitoring. One system watches both sides. An environment that can only report on itself has a blind spot exactly where it hurts - and the monitor itself is on that list, which is what outside-in checks are for.
- Backups. Two layers, two restore paths: VM-level backups for whole-machine recovery, plus filesystem snapshot replication (copying point-in-time filesystem states to another location) for the data underneath - kept apart, because layers only count when one compromise cannot reach both.
- Workloads. Everything else - git hosting, mail, the agent tooling, media, and the applications described on /projects.
The boundaries
The rules that make the setup boring to operate:
Public and private do not mix. Public traffic enters through the hosted ingress and nowhere else. Management interfaces, hypervisors (software that runs and isolates virtual machines), and storage are only reachable over the VPN.
Every workload gets the cheapest boundary that still isolates it. A small trusted tool runs as a systemd service. A dependency-heavy one gets a container. Anything with a real security or failure boundary gets its own VM. The goal is understandable failures, not expensive maximum-isolation cosplay.
Backups only count when the restore path is understood. A green backup job is a claim, not a guarantee. Treating it as proof can hide a pile of unrestorable garbage behind a green check mark. Restores get thought through - and occasionally exercised - before something forces the issue.
What this buys
Describing infrastructure by role is an opsec (practice of limiting information that could help an attacker) habit that doubles as a design test: if the architecture only makes sense once you know the hostnames, it is not an architecture, it is an accumulation. The version above fits in a page, and the real one behaves the same way.
The short version, with pictures, is on /about.