Caddy as the only door into the rack

One door, and what that buys you

The rack has exactly two public ports: 80 and 443, both on Caddy. Nothing else is forwarded, so the attack surface of the whole house is one binary that is designed to be exposed.

It also fixes the port-number problem. Behind the proxy, every service can listen on its upstream default — Grafana on 3000, Immich on 2283, Uptime Kuma on 3001 — and you reach them by name instead of by remembering numbers. The port band still exists for the panels you hit directly on the LAN, but day to day you type grafana.lan.

Internal certificates for .lan names

Public ACME cannot issue for a name that does not exist in public DNS, and a self-signed certificate you generate by hand has to be re-trusted on every device. Let's Encrypt's own documentation for private networks is what Caddy implements as tls internal: it runs a local CA, issues to your hostname, and you install one root certificate once per device.

The root is written to /data/caddy/pki/authorities/local/root.crt in the container's data volume. Copy it to your laptop, add it to the trust store, and every .lan name gets a padlock with no warnings.

# copy the local root out of the container and trust it on a Mac
sudo docker cp caddy:/data/caddy/pki/authorities/local/root.crt ./beaconbox-root.crt
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain ./beaconbox-root.crt

The Caddyfile, and why there is only one

There is no include system and no sites-available directory, because there does not need to be one. A Caddyfile this size is readable in a single screen, and a file you can read in one screen is a file you will actually review before changing.

The (secure) snippet carries the header policy, and the (lan) snippet carries the internal TLS plus the LAN-only address match. Each service block is then three lines.

(secure) {
  header {
    Strict-Transport-Security "max-age=31536000; includeSubDomains"
    X-Content-Type-Options "nosniff"
    Referrer-Policy "strict-origin-when-cross-origin"
  }
}

(lan) {
  tls internal
  @notlan not remote_ip 192.168.10.0/24 172.20.0.0/24
  respond @notlan "not here" 403
}

rack.twinkling.top {
  import secure
  reverse_proxy jellyfin:8096
}

grafana.lan {
  import lan
  reverse_proxy grafana:3000
}

immich.lan {
  import lan
  reverse_proxy immich-server:2283
}

Pointing at container names

reverse_proxy takes the container name directly because Caddy joins the same user-defined bridge network as everything else. That is why every compose file on this rack ends with networks: [rack] and the network itself is created once with external: true.

The corollary is that container_name matters. Rename a container and every proxy entry pointing at the old name starts returning 502 while the container itself is perfectly healthy.

docker exec caddy wget -qO- http://immich-server:2283/api/server/ping
# if this fails from inside caddy, the problem is the network, not the config

Logs, and keeping them small

Access logs are off by default and that is the right default for a house. Turn them on for one hostname at a time when you are debugging, and let the host's logrotate deal with them rather than the container.

What is worth keeping permanently is the certificate renewal line. One grep a month tells you whether automatic HTTPS is still doing its job.

docker logs --since 720h caddy 2>&1 | grep -i 'certificate obtained' | tail -5

compose file

Drop the whole file at /srv/homelab/caddy/compose.yaml. Tags are pinned, never latest: rolling back on a Pi is far more work than upgrading.

services:
  caddy:
    image: caddy:2.9.1-alpine
    container_name: caddy
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "127.0.0.1:2019:2019"
    environment:
      ACME_EMAIL: [email protected]
    volumes:
      - /srv/homelab/caddy/Caddyfile:/etc/caddy/Caddyfile:ro
      - /srv/homelab/caddy/data:/data
      - /srv/homelab/caddy/config:/config
    networks: [rack]

networks:
  rack:
    external: true

Hardening checklist

• the admin API binds to 127.0.0.1:2019 so a stray curl on the LAN cannot rewrite the config
• no service is exposed directly; every hostname resolves to Caddy and Caddy decides who gets in
• basic auth on the two panels that have no login of their own, with the hash generated by caddy hash-password
• security headers (HSTS, X-Content-Type-Options, Referrer-Policy) set once in a snippet and imported by every site block
• tls internal for the .lan hostnames, real certificates only for the two names that leave the house

Verify it went in clean

• curl -I https://rack.twinkling.top returns 200 with an HSTS header present
• The .lan hostnames load with a valid padlock on a device that has the internal root installed
• docker logs caddy shows 'certificate obtained successfully' for the public name after the first boot
• Port 2019 answers on the Pi itself and refuses from another machine on the LAN

Hardware questions

Caddy or nginx for a home rack?

Caddy if you want certificates to be someone else's problem, which on a home network you do. nginx if you already know nginx and want the Lua and cache modules. The performance difference at household traffic levels is not measurable; the configuration difference is a four-line file versus a certbot timer, a cron job and a renewal hook.

How much memory does the proxy add to a 4 GB Pi?

About 45 MB resident for nine proxied hostnames. This is one of the few containers on the rack that you can size by ignoring it.

Should the proxy run on the same Pi as everything else?

Yes, until it is the reason you cannot reach anything. Running it on the same board costs nothing and keeps the network simple; the day you add a second Pi is the day it becomes worth moving the proxy to the smaller one so you can reboot the busy board without taking the front door down.