Back to projects

self-hosted · 24/7

Homelab

Proxmox, containers and reverse proxy

One Proxmox server, about twenty LXC containers, a Caddy reverse proxy and backups — including this site, running in one of them.

Why

To learn infrastructure by doing it, and because a QA who does not know where the thing under test runs misses half the bugs. The lab also serves as a sandbox: a deployment regression shows up here before it shows up in production.

The architecture

Proxmox VE 9.2, a single host, and one LXC container per service rather than one big VM: independent updates, isolated failures, selective backups. It runs AdGuard (DNS), Vaultwarden, Immich, Jellyfin, Meilisearch, Miniflux, the *arr media stack, OpenCloud, and a few home-made tools.

Caddy handles the reverse proxy and certificates: one block per service, automatic TLS, HSTS. Every domain points to the same public IP, and Caddy decides where the request goes.

This site runs in container 217: Node and Express on port 3000, Caddy in front, PM2 to restart the process. Proxmox Backup Server for backups, rclone for the off-site copy.

What broke

A Proxmox upgrade changed container networking behaviour: no outbound internet, while everything else answered. Diagnosis took an hour, less because of the problem than because I was looking in the wrong place — inside the containers, while the fault was on the host.

Second classic: a “successful” backup that restored nothing. The job ran, the file existed, and the restore failed on a missing dependency. Since then a backup is only valid once a restore has been tested.

What I keep from it

Three habits that came from this and that I use daily in QA: isolate before fixing, read the logs of whoever reports the error — not just whoever produces it — and never trust a green light before making it lie once.