I learned most of it at home.

The architecture

How the layers work together — from the device on the road to the data.

What I have built privately

How I work

Six principles that show up in this setup.

• Describe first, then build. Address plan, services and access rules live under version control (Git). The description is the source of truth, not my memory — six months from now as well.
• No backup without a rehearsal. A backup whose restore was never tested is a hope. I restore it before I call it a backup.
• Access only through identity. Every service sits behind a sign-in with a second factor; several failed attempts trigger a lock and a notification to me. No service is reachable "just quickly" without protection.
• Changes stay traceable. Every configuration change is a version with a reason. When something breaks I want to know what I changed and when — not guess.
• Report instead of searching. Thresholds, outages and failed sign-ins raise alerts. I find out before someone calls.
• Less surface to attack. What I do not need is switched off rather than just unused; permissions as narrow as possible; credentials in a vault instead of a file on the desktop.

Technology in use

Tools I run here every day — not from a catalogue, but in operation.

• Proxmox VE
• LXC containers
• Docker & Compose
• ZFS
• TrueNAS
• Nginx Proxy Manager
• AdGuard Home
• Authelia with TOTP
• WireGuard
• Cloudflare Tunnel
• NetAlertX
• Home Assistant
• Shelly
• Python
• Bash
• Git
• Cron

Remote access to the internal network runs over WireGuard — that way I work on the same systems on the road as I do at home, without exposing any interface to the open internet.

From practice — four faults, four lessons

The interesting stories are not the ones where everything worked, but the others.

• A smart device took a server's address. The service was unreachable for a few minutes. Cause: the range used for automatic addressing contained the servers' addresses — a device without a fixed address received exactly the address that was already in use. Fixed: moved automatic addressing behind every fixed place, then checked every device individually. That uncovered a second case: the central storage was still getting its address automatically, which would have broken every connection on the next lease change. Lesson: an addressing plan is only as good as the check that follows it.
• A device answered but was not reachable. The management interface reported the device as fine — the controller still could not reach it. Cause: the device was stuck on an old address while the controller's cache still held the old value. Fixed: verified the address at the device itself (cross-checked via its hardware address), corrected the cache, restarted the controller — in exactly that order, otherwise the restart pulls the old state back. Lesson: when the interface and reality disagree, reality wins.
• The host stalled under load. Under write load on the disks the virtualisation host became slow to the point of being unusable. Cause: the transfer path the virtual machines use to reach the disks. Fixed: switched to a different transfer path and added monitoring for stalled systems. No failures of that kind since. Lesson: damping symptoms does not help — without the cause, the fault comes back.
• A hardening test instead of an assumption. After rebuilding remote access I requested every published address without signing in: all of them answered "access denied", not a single interface was visible. Also verified: after several failed attempts the lock kicks in and sends me a notification. Lesson: "should be protected" is not proof — I test it, before anyone else does.

And professionally