Where Certbot in Docker gets painful
The usual setup is a dedicated Certbot container, a shared volume for certificates, a cron job or systemd timer to trigger renewal, and a hook to reload whichever container is actually serving traffic once a new certificate lands. Every piece of that is a place things quietly break: the reload hook stops firing after a compose file change, the volume mount path drifts between environments, or the renewal container itself stops running and nobody notices until a certificate expires.
Alternatives that avoid the sidecar
Caddy issues and renews certificates automatically as part of serving traffic — no separate container, no cron job, no reload hook, because the same process doing the serving is the one managing the certificate.
Traefik does the same as a reverse proxy in front of other containers, with ACME configuration living in the same place as routing rules — useful if you already want a reverse proxy layer rather than exposing nginx directly.
acme.sh is a lighter-weight shell-script alternative to Certbot itself — smaller footprint, no Python dependency, and it supports the same ACME providers. It still needs the same renewal-and-reload wiring Certbot does, so it doesn't remove the sidecar problem on its own.
A managed load balancer (a cloud provider's ALB, or a platform like Fly.io, Render or Railway) can take certificate management out of the container stack entirely, terminating TLS before traffic ever reaches your containers.
Whichever you use, verify it independently
Every one of these tools can fail silently in the same way Certbot can — a renewal that stops running, a reload that doesn't happen, a chain that's served incomplete. SUN-DRAM Scanner doesn't issue or renew certificates — it reads what a hostname is actually presenting right now, regardless of which tool put it there, and tells you plainly whether it's something to worry about.