Server.

The repository is deliberately tiny and declarative. A single Caddyfile maps 13 reverse-proxy blocks to local ports, and Caddy handles automatic HTTPS on top, so the file doubles as both routing config and the canonical inventory of what runs on the machine. Editing one block is the entire interface for adding, moving, or removing a service.

Deployment is a paths-filtered GitHub Action that only fires when the Caddyfile changes. It copies the file to /etc/caddy via scp over SSH, runs systemctl reload caddy, and then diffs the new Caddyfile against the previous commit to drive DNS. The reload-not-restart choice keeps existing connections alive, and gating on the file path means unrelated commits never touch production.

The DNS reconciler is the genuinely clever part: a 73-line Python script with zero third-party dependencies, talking to the GoDaddy v1 API through urllib alone. It parses host lines out of both the old and new Caddyfile into sets of (root domain, record name) tuples, correctly splitting subdomains from their registrable root and expanding bare apex domains into both @ and www records. Set difference then yields exactly the records to PUT and to DELETE, so DNS converges to match the proxy config declaratively rather than through imperative steps. Deletes treat a 404 as success, making the operation idempotent and safe to re-run.

Operational rigor rounds it out. A recovery guide documents a full Hetzner rebuild that preserves the IP so DNS stays valid, plus the SSH known-hosts and Caddy reinstall steps, and an infrastructure doc captures the Docker and Caddy layout. Secrets for the server and the GoDaddy API are kept in GitHub Actions secrets, never in the repo.