Automatic HTTPS with Caddy

copydig +short app.example.com
# should print the server's IP — if it prints nothing, DNS hasn't propagated yet

copysudo ufw allow 80
sudo ufw allow 443
sudo ufw enable

copy# /etc/caddy/Caddyfile
app.example.com {
  reverse_proxy localhost:3001
}

#Run Caddy alongside your app in Compose

The clean pattern is to put Caddy in the same Docker network as the app it proxies, so it can reach it by service name:

copyservices:
  app:
    image: louislam/uptime-kuma:1
    restart: unless-stopped

  caddy:
    image: caddy:2
    ports: ["80:80", "443:443"]
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
      - caddy_config:/config
    restart: unless-stopped

volumes:
  caddy_data:
  caddy_config:

With app and caddy on the same Compose network, the Caddyfile target becomes the service name and its internal port — not localhost:

copyapp.example.com {
  reverse_proxy app:3001
}

Two volumes matter here, not just one. caddy_data stores the issued certificates and the ACME account key — losing it means every restart looks like a brand-new install to Let's Encrypt, which is how people accidentally burn into rate limits. caddy_config stores Caddy's autosaved running configuration; it's smaller in consequence but still worth persisting so a container replacement doesn't silently reset it.

Bring it up and confirm both containers are actually running:

copydocker compose up -d
docker compose ps
# NAME     IMAGE          STATUS
# app      ...            Up
# caddy    caddy:2        Up

#Verify HTTPS is actually issued and working

Don't just eyeball the padlock icon — check it from the command line so you know exactly what happened.

Watch Caddy issue the certificate. Tail the logs right after you hit the domain for the first time (or right after docker compose up -d if DNS was already live):

copydocker compose logs -f caddy

A healthy first issuance looks like this (Caddy logs structured JSON by default):

copy{"level":"info","logger":"tls.obtain","msg":"acquiring lock","identifier":"app.example.com"}
{"level":"info","logger":"tls.obtain","msg":"obtaining certificate","identifier":"app.example.com"}
{"level":"info","logger":"tls.issuance.acme","msg":"trying to solve challenge","identifier":"app.example.com","challenge_type":"http-01"}
{"level":"info","logger":"tls.obtain","msg":"certificate obtained successfully","identifier":"app.example.com"}
{"level":"info","logger":"tls.obtain","msg":"releasing lock","identifier":"app.example.com"}

Confirm the cert from outside. curl -v shows the full TLS handshake and the certificate chain that was actually presented:

copycurl -v https://app.example.com 2>&1 | grep -E "subject:|issuer:|SSL certificate|HTTP/2"
#  subject: CN=app.example.com
#  issuer: C=US; O=Let's Encrypt; CN=E5
#  SSL certificate verify ok.
# < HTTP/2 200

The issuer line is the useful part: if it says Let's Encrypt, the real production certificate issued. If it says something like Caddy Local Authority, you're looking at Caddy's internal self-signed CA, which means the ACME step never completed and Caddy fell back to a local cert to avoid serving plain HTTP — that's a signal to go check the logs, not a working state.

Confirm the redirect. Plain HTTP should 308-redirect to HTTPS, not serve content:

copycurl -I http://app.example.com
# HTTP/1.1 308 Permanent Redirect
# Location: https://app.example.com/

#Add more apps in seconds

Each new app is one more block in the same Caddyfile:

copygit.example.com   { reverse_proxy gitea:3000 }
notes.example.com { reverse_proxy outline:3000 }

Reload without dropping connections:

copydocker compose exec caddy caddy reload --config /etc/caddy/Caddyfile

caddy reload does a graceful config swap — existing connections finish, new ones use the new config — so you don't need to restart the container. Each new hostname gets its own certificate issued independently on first hit.

#Harden it for production

The two-line Caddyfile is correct but bare. A few additions are worth making before you put anything real behind it.

Security headers. Caddy doesn't set HSTS or other hardening headers by default — add them explicitly with a header block:

copyapp.example.com {
  header {
    Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
    X-Content-Type-Options "nosniff"
    X-Frame-Options "DENY"
    Referrer-Policy "strict-origin-when-cross-origin"
    -Server
  }
  reverse_proxy app:3001
}

The -Server line removes the Server response header entirely rather than advertising Caddy to anyone probing the box. Be deliberate with preload on HSTS — submitting a domain to the HSTS preload list is very hard to reverse.

Restrict access to admin UIs. A lot of self-hosted tools (dashboards, *-admin panels) shouldn't be open to the whole internet just because they're behind TLS now. Caddy's basic_auth directive gates a site behind HTTP basic auth, with the password stored as a bcrypt hash — never plaintext in the Caddyfile:

copydocker compose exec caddy caddy hash-password
# prompts for a password, prints a $2a$... bcrypt hash

copyadmin.example.com {
  basic_auth {
    admin $2a$14$replace-with-the-hash-from-above
  }
  reverse_proxy admin-app:8080
}

For something more binary, restrict by source IP instead using a named matcher:

copyadmin.example.com {
  @notallowed not remote_ip 203.0.113.0/24
  respond @notallowed 403
  reverse_proxy admin-app:8080
}

Log rotation. With no log directive, Caddy writes only its own startup/admin logs to stdout, which docker compose logs reads and which Docker's own log driver rotates according to its daemon config (worth checking docker info | grep -i logging isn't set to unbounded). If you want structured per-site access logs instead, Caddy writes and rotates them itself:

copyapp.example.com {
  log {
    output file /var/log/caddy/app.example.com.log {
      roll_size 10MB
      roll_keep 10
      roll_keep_for 720h
    }
  }
  reverse_proxy app:3001
}

Caddy rolls even without those sub-options (100 MB / 10 files / 90 days by default) — the block above just makes the retention explicit rather than relying on the defaults.

#Troubleshooting

"DNS problem: NXDOMAIN" in the logs. This is Let's Encrypt telling Caddy the domain doesn't resolve yet — you started Caddy (or hit the domain) before the A record propagated:

copy{"level":"error","logger":"tls.obtain","msg":"could not get certificate from issuer","identifier":"app.example.com","error":"... urn:ietf:params:acme:error:dns ... DNS problem: NXDOMAIN looking up A for app.example.com - check that a DNS record exists for this domain"}

Fix: confirm with dig +short app.example.com, wait for it to return the right IP, then hit the domain again (or caddy reload) — Caddy retries issuance on the next request, you don't need to restart the container.

Certificate never issues, no error either. Almost always the cloud firewall, not Caddy — see "Open ports 80 and 443" above. Test from outside the box, not from localhost on the box itself:

copycurl -v --connect-timeout 5 http://app.example.com
# curl: (28) Connection timed out — nothing reached the box at all

A connection timeout (not "connection refused") on port 80 or 443 from an external host, while ufw status shows the ports open locally, points straight at the provider's network firewall panel.

Port already in use. If Caddy's container won't start and logs address already in use for :80 or :443, something else on the host — Nginx or Apache from an earlier setup, or a stray Caddy process — already owns it:

copyss -tlnp | grep -E ':80|:443'

Stop or reconfigure whatever owns the port; Caddy can't share it.

Hitting Let's Encrypt rate limits while testing. Let's Encrypt caps failed validations at roughly 5 per account/hostname/hour, and duplicate certificates for the same exact hostname set at 5 per week. If you're iterating on a Caddyfile and re-triggering issuance repeatedly, switch to the staging CA first — it has much higher limits and issues certs your browser won't trust, which is exactly what you want while debugging:

copy{
  acme_ca https://acme-staging-v02.api.letsencrypt.org/directory
}

app.example.com {
  reverse_proxy app:3001
}

Once docker compose logs caddy shows a clean issuance against staging, delete the acme_ca override (or point it back at the production directory) and reload — Caddy will issue a real, trusted certificate on the next request.

Caddyfile syntax error. A malformed Caddyfile makes the container crash-loop rather than start with a broken config. Validate before you reload:

copydocker compose exec caddy caddy validate --config /etc/caddy/Caddyfile

It reports the exact line and the parse error (typically a missing {/} or a directive typo), which is faster than reading through docker compose logs caddy for a startup stack trace.

#Where to go next

Need the Docker base layer first? See Docker & Compose on Ubuntu. Then pick an app from the self-hosting guides and drop it behind Caddy — the pattern above (one Caddyfile block per hostname, shared caddy_data/caddy_config volumes, headers and auth on anything admin-facing) scales to as many apps as one box can run.