By default Caddy provisions a Let’s Encrypt cert automatically over HTTP-01 — nothing to configure. Two other modes cover the cases automatic HTTPS can’t.
Bring your own cert
Automatic HTTPS can’t work when something in front of your box terminates TLS — most commonly a Cloudflare proxy (orange-cloud). Serve a cert you provide instead:
tls: manual # serve an uploaded cert, don't provision one via ACMEThen upload the cert + key — they travel over ssh stdin, never argv; the private key is treated like a secret:
homeport tls set fullchain.pem privkey.pem # e.g. a Cloudflare Origin Certificate
homeport tls clear # revert to automatic HTTPShomeport never installs a cert on its own — this is entirely opt-in. Pair it
with Cloudflare’s SSL/TLS mode set to Full (strict). (tls: manual needs a
public domain — not for internal or path-mounted apps.)
DNS-01 certificates (any provider)
Instead of a hand-managed cert, let Caddy issue real, auto-renewing Let’s Encrypt certs via DNS-01 — it proves ownership by writing a TXT record through your DNS provider’s API, so it works behind a TLS-terminating proxy. Generic across every caddy-dns provider:
homeport server plugins add github.com/caddy-dns/cloudflare # 1. the provider plugin
homeport server caddy-env HOMEPORT_DNS_CLOUDFLARE # 2. API token (via stdin)tls: dns:cloudflare # 3. per app — or dns:digitalocean, dns:route53, …The token env var defaults to HOMEPORT_DNS_<PROVIDER>; set dns_token_env: to
use a different name, or dns_token_env: none for providers that read standard
SDK env vars (e.g. route53 with AWS_ACCESS_KEY_ID — set those via caddy-env
too). Tokens travel over ssh stdin, live root-owned on the box, and reach Caddy
through a systemd EnvironmentFile — never argv, never git. Use a token scoped
to DNS-edit on the one zone.