Caddy: The Web Server That Handles TLS So You Don't Have To

Automatic HTTPS, certificate rotation, and modern TLS defaults — out of the box. In 2023, a post-mortem report from a mid-size SaaS company revealed that their three-hour outage traced back to one root cause: a forgotten TLS certificate that expired on a Saturday morning. The on-call engineer was asleep. The monitoring alert fired too late. The fix took six minutes once someone woke up — but the damage was done. That scenario is more common than most teams admit. And it is exactly the class of problem Caddy was built to eliminate. Setting Caddy is an open-source web server written in Go, maintained by the community around Matt Holt and the caddyserver organization. With nearly 72,000 GitHub stars, it has moved well past "interesting side project" territory. The core premise is simple but consequential: HTTPS should be the default, not the exception, and the operational burden of managing certificates should fall on the server — not the operator. Traditional setups require you to provision a certificate from Let's Encrypt (a free certificate authority), configure your web server to use it, write a cron job or systemd timer to renew it before it expires, and pray that none of those moving parts drift out of sync. Caddy collapses that entire workflow into zero configuration. The Story Here is what "automatic HTTPS" actually means in practice. You point Caddy at a domain, and it contacts Let's Encrypt (or ZeroSSL, another supported CA) using the ACME protocol (Automated Certificate Management Environment — the standardized way machines request and renew TLS certificates). It completes the domain ownership challenge, receives a certificate, stores it, serves it, and rotates it before expiry. All of this happens without a restart, without a cron job, and without a human. A minimal Caddyfile — Caddy's configuration format — for a production HTTPS site looks like this: example.com { reverse_proxy localhost:3000 } That is the entire file. Caddy infers that you want HTTPS, negotiates the certificate on first run, and begins proxying traffic to your backend on port 3000. Compare that to the equivalent nginx + certbot setup: a server block with SSL directives, a certbot invocation, a renewal hook, and periodic verification that the hook actually runs. From a security posture standpoint, the gains go deeper than convenience. Caddy's defaults enforce TLS 1.2 as the minimum version, with TLS 1.3 preferred. Older protocols — SSL 3.0, TLS 1.0, TLS 1.1 — are disabled by default. The default cipher suite list favors forward-secrecy algorithms (ECDHE key exchange, which ensures that even if a private key is later compromised, past sessions cannot be decrypted). You have to explicitly opt out of these safe defaults, rather than opt in — which reverses the usual risk direction. For teams handling compliance requirements like PCI-DSS or SOC 2, those defaults map directly to auditor checklist items: "TLS 1.2 minimum enforced? Yes. Forward secrecy enabled? Yes. Certificate auto-renewed? Yes." Caddy does not make compliance automatic, but it removes several of the most common manual failure points. Caddy also supports HTTP/3 (QUIC-based transport, which reduces connection latency and improves performance on lossy networks) alongside HTTP/1.1 and HTTP/2 — making it one of the few production-grade servers with out-of-the-box HTTP/3 support. For internal infrastructure — services behind a private network where Let's Encrypt's public challenge cannot reach — Caddy supports DNS-01 ACME challenges via provider plugins, enabling certificate issuance without exposing port 80 to the internet. It also supports integration with internal certificate authorities for fully private PKI setups. The Insight The real security argument for Caddy is not that it adds new defenses. It is that it removes a persistent human failure mode from the critical path. Certificate expiry, misconfigured cipher suites, forgotten renewal jobs — these are not exotic attack vectors. They are boring operational mistakes that cause real incidents. Caddy's design philosophy is that secure defaults should require no work to maintain, and that the cost of staying secure should not compound over time as your infrastructure grows. For a startup running a handful of services, that means no devops overhead for TLS. For an enterprise with dozens of internal services, it means the same certificate hygiene at scale without a dedicated PKI team. For a solo maker hosting a side project, it means waking up Monday morning to a server that renewed its own certificate over the weekend. None of that is magic. It is just good engineering applied to a problem that most teams treat as solved-but-actually-fragile. If you work with web infrastructure at any scale and TLS management still lives in a cron job or a shared runbook, Caddy is worth a serious weekend evaluation. More security-focused tooling — vetted for the same practical lens — lives at teum.io/stories. 한국어 요약 Caddy는 Go로 작성된 웹 서버로, TLS 인증서 발급부터 자동 갱신까지 설정 없이 처리해 줍니다. Let's Encrypt ACME 프로토콜을 내부적으로 구현해 인증서 만료로 인한 장애를 구조적으로 차단합니다. 기본값이 TLS 1.3 우선, 순방향 비밀성(Forward Secrecy) 활성화로 설정되어 있어 PCI-DSS, SOC 2 등 컴플라이언스 체크리스트 항목 상당수를 자동으로 충족합니다. 스타트업부터 내부 서비스가 많은 엔터프라이즈까지 TLS 운영 부담을 줄이고 싶은 팀이라면 실무 적용을 검토해 볼 만한 도구입니다. Caddy's design philosophy is that secure defaults should require no work to maintain, and that the cost of staying secure should not compound over time as your infrastructure grows.