Run Caddy as a service

caddy run in a terminal dies with your SSH session. A real server needs Caddy supervised: started at boot, restarted after a crash, logging somewhere durable. On Linux that supervisor is systemd, and the official package already did the setup for you.

See what got installed:

systemctl status caddy
systemctl cat caddy

status shows whether Caddy is running, since when, and its recent log lines. cat prints the unit file itself. Read it once — it answers most questions about how Caddy runs: as the dedicated caddy user, loading /etc/caddy/Caddyfile, restarting on failure. Notice the ExecReload line too: it means systemctl reload caddy maps to Caddy’s graceful reload, so configuration changes don’t require a restart.

Logs go to the journal:

journalctl -u caddy --since today
journalctl -u caddy -f

The first command shows today’s runtime log: startup, certificate activity, errors. The second follows it live, which is what you want open in a second terminal while changing configuration.

The service user matters more than people expect. caddy is an unprivileged account. The unit grants it just enough capability to bind ports 80 and 443, it can read /etc/caddy, and it writes its own state under /var/lib/caddy. It cannot read your home directory. That is the number-one source of “it works with caddy run but not as a service”: you tested as your own user, and the service user can’t reach the files.

Fix permission problems narrowly. Move site files somewhere sensible like /srv/www, make them readable by the caddy group, and confirm with sudo -u caddy ls /srv/www. Don’t chmod 777 a directory tree to make an error disappear — you’d be trading a visible failure for an invisible one.

My advice: on servers, skip caddy start (Caddy’s own backgrounding) entirely. It leaves a process that nothing supervises. The systemd service gives you boot integration, restart policy, and one obvious place to look when something breaks.