Tool in production

Caddy

The web server that makes HTTPS easy. Automatic certificates, HTTP/3, declarative configuration — a concrete alternative to and Traefik for agencies and hosters.

Project profile

Caddy

Ultimate Server with Automatic HTTPS

As of: June 1, 2026

GitHub stars

73k

Forks

4.8k

Open issues

249

License

Apache-2.0

Latest version

v2.11.3

Language

First release

January 13, 2015

Last commit

May 29, 2026

→ GitHub repository → Official website → Documentation

Third-party source · Wikidata (CC0)

Wikidata profile

Caddy

Q24008327

License

Apache Software License 2.0

→ Wikidata entry

What is Caddy?

Caddy is a web server and , written in Go, open source under Apache-2.0. Comparable to or Apache — with one decisive difference: certificates are fetched automatically, renewed automatically, swapped in automatically. No Certbot, no job, no 90-day alarm clock.

Configuration runs through the declarative Caddyfile syntax — three lines are enough for a working HTTPS site. Plus: HTTP/3, Brotli, Zstd, hot reload, JSON for automation, plugin system via xcaddy. Caddy has existed since 2015, version 2 runs in production at Cloudflare, Stripe and Mercedes-Benz.

Why a web agency uses Caddy

A web agency typically runs 20–50 client domains in parallel — WordPress, Statamic, Next.js, headless CMS, online shops. In that means: 30 server blocks, 30 Certbot paths, 30 renewal hooks, 30 ways for a certificate to silently expire.

Caddy collapses that into one Caddyfile with an import directive. SSL runs in the background, new domains go live with hot reload, no service restart. The agency trades 30 points of potential failure for one point of correct automation — a heavy simplification of operational responsibility.

Client case study

Web agency Pixelhaus

Five employees, 30 active client domains, migrated from + Certbot to Caddy three years ago. Before: regular SSL outages because a job ran, a hook was missing or a renewal hook hit the wrong directory. Now: one Caddyfile, no , no outages.

Auto-SSL for 30 client domains

Every new client domain gets a valid certificate without manual intervention. Renewal runs automatically, no jobs, no pre/post hooks, no directory magic.

HTTPS enforcement + www redirect

All client sites must enforce HTTPS consistently and redirect the www subdomain to the apex — without every site config carrying the same 8-line boilerplate.

Reverse proxy to backend containers

Behind the Caddy sites run PHP-FPM for WordPress, Node containers for Next.js, Strapi on its own ports. Caddy should hit these as a — one configuration line per site.

Security headers centrally

HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy should apply to all client sites with the same default — individual sites may deviate, but the standard is set once.

Compression + HTTP/3

Brotli + Zstd + Gzip fallback for modern browsers, HTTP/3 + QUIC for mobile. Should work out of the box, without compiling or installing separate modules.

Hot reload without downtime

A new client domain is enabled at noon — no service restart, not one second of downtime on the other 29 sites. Reload has to be atomic.

What now runs in the Caddy setup

Eight productive configuration patterns the agency has used for three years. Each template is its own Caddyfile import, ready to copy for new clients.

WordPress behind PHP-FPM

Five lines of Caddyfile: root directory, php_fastcgi pointed at the local socket, file_server as fallback. Auto-SSL, HTTPS redirect and HTTP/3 are implicit. Works identically for every one of the agency's 18 WordPress sites.

Next.js SSR via reverse proxy

reverse_proxy to localhost:3000 or the container name. Caddy terminates SSL, Next.js speaks HTTP. One extra directive sets the correct X-Forwarded headers — beyond that, no setup.

Static site (file_server)

Astro, Hugo or Eleventy build dropped into a directory. Site block: root + file_server + try_files for SPA routing. Six lines for a fully fledged static site with HTTPS.

Headless Strapi on a subdomain

.clientX.com proxied to strapi:1337 in the network. Encode gzip + zstd for JSON responses. CORS headers are set inside Strapi, Caddy just passes them through. Clean separation of web and .

Mailcow web UI subdomain

mail.clientX.com proxied to Mailcow's internal . Important: the auto-SSL for the mail domain is also the TLS cert for the Mailcow services. One domain, one configuration, no separate Mailcow ACME client needed.

Uptime Kuma status page

status.agency.com proxied to the backend. Public status page for client visibility, the actual admin UI only reachable over a subdomain. Two Caddy site blocks for one tool.

Apex + www + staging

One site definition with three host names: clientX.com, www.clientX.com, staging.clientX.com. A matcher for staging routes to a different backend (PR preview container). Clean multi-environment configuration without a second file.

Wildcard DNS + DNS challenge

*.preview.agency.com with a wildcard cert via DNS challenge against the Hetzner DNS provider. Every PR gets a unique preview URL — all share one certificate. Caddy plugin: caddy-dns/hetzner via xcaddy.

Core capabilities of Caddy

What makes Caddy distinctive as a web server — and which capabilities actually carry an agency setup.

Automatic HTTPS

certificates are fetched on first request, renewed automatically, rotated automatically. ZeroSSL as fallback, OCSP stapling automatic. No Certbot, no , no renewal hook — Caddy is an ACME client and web server in one binary.

HTTP/3 + QUIC out of the box

HTTP/3 has been on by default since Caddy 2.6. No extra modules, no separate UDP configuration — compatible with every current mobile application. ALPN is negotiated automatically.

Caddyfile — declarative, not procedural

One site = one block. One directive = one line. No if conditions, no sed magic, no quoting hell like . Caddyfile is explicitly optimised to be readable by humans, not by parsers.

Hot reload without downtime

`caddy reload` loads the new Caddyfile atomically — running connections keep being served, new ones go to the new config. No connection drop, no service restart. With that exact guarantee takes great care; with Caddy it is the default.

JSON config + admin API

Caddyfile is only sugar. Internally the configuration is a JSON object, manipulable through a local on port 2019. workflows, Ansible playbooks or custom scripts can add domains via HTTP PATCH — fully automatable.

Plugin ecosystem via xcaddy

xcaddy is the Caddy builder: pick plugins from the registry (DNS providers, auth backends, geo IP, rate limiting), xcaddy builds a matching Caddy binary in 30 seconds. Over 200 official plugins, all Apache-2.0.

Honest alternatives

If Caddy is not a fit — what else?

Three web servers on the market, all three production-grade. Each has a reason why people use it — and at least one reason why people avoid it. Honest framing here — no marketing romance.

Market leader

nginx

F5 (formerly NGINX Inc.), BSD-2

+ Established market leader, huge community
+ Extremely performant, well documented
− Auto-SSL only via Certbot + cron job
− Lots of config boilerplate, sed magic common

Docker focused

Traefik

Traefik Labs, MIT license

+ Auto-discovery of Docker containers via labels
+ Auto-SSL similar to Caddy
− Higher configuration complexity
− Less suited without container orchestration

Classic

Apache httpd

Apache Foundation, Apache-2.0

+ 30+ years established, runs on everything
+ Flexible .htaccess for shared hosting
− Auto-SSL only via mod_md or Certbot
− Outdated for modern stack architectures

Rule of thumb: if you already know and only run a handful of domains, there is no pressure to switch. If you run 20+ domains, need auto-SSL and hot reload, or want to live without Certbot dance, you are productive on Caddy after 30 minutes. Traefik is the other strong argument for Docker-centric setups — choice is a matter of taste.

Pricing

Apache-2.0. Clean. No asterisks.

License

Apache-2.0 — an OSI-approved open-source license with no branding clause, no anti-competition clause, no sustainable-use asterisk. Read the source, change it, sell it commercially, all permitted.

Running costs

One VPS that would have run a web server anyway. Caddy replaces nginx or Apache 1:1, no extra license or cloud costs. Hardware requirements identical to nginx.

Effort

First HTTPS site live: 3 minutes (download binary, three lines of Caddyfile, start). Migrating a 30-domain agency from nginx to Caddy: 1 consulting day including snippet library and hot-reload workflow.

Unlike or , Caddy is classic open source — no 'fair-code', no custom license, no branding obligation. Refreshing. A complete Apache-2.0 software, stable for ten years and running in production at Cloudflare, Mercedes-Benz and Stripe.

Site block with security headers and Brotli

example-shop.com, www.example-shop.com {
  redir https://example-shop.com{uri} permanent

  encode br zstd gzip

  header {
    Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
    X-Frame-Options DENY
    X-Content-Type-Options nosniff
    Referrer-Policy strict-origin-when-cross-origin
  }

  root * /var/www/example-shop
  php_fastcgi unix//run/php/php8.3-fpm.sock
  file_server

  log {
    output file /var/log/caddy/shop-access.log
    format json
  }
}

A shop domain with HSTS, X-Frame-Options, Brotli + Zstd compression and JSON logging — all declarative, no sed magic. Source: own practice, Apache-2.0.

Example Caddyfile — 30 client domains in one file

{
  email admin@agency.com
}

import sites/*.caddy

# sites/clientA-wordpress.caddy
clientA.com, www.clientA.com {
  redir https://clientA.com{uri} permanent
  root * /var/www/clientA
  php_fastcgi unix//run/php/php8.3-fpm.sock
  file_server
}

# sites/clientB-nextjs.caddy
clientB.com {
  reverse_proxy localhost:3000
  header Strict-Transport-Security "max-age=31536000"
}

# sites/clientC-strapi-api.caddy
api.clientC.io {
  reverse_proxy strapi:1337
  encode gzip zstd
}

Agency setup: global defaults, then an import collector. Each client site is 3–8 lines of Caddyfile. SSL is automatic, HTTPS redirect implicit. Source: own practice, Apache-2.0.

Caddy is the door — what is behind it?

Caddy is the entry server. Workflows are orchestrated by , monitoring runs on , the stack hangs off the backend. The full picture:

→ n8n (workflow automation)→ Uptime Kuma (monitoring)→ Overview of all tools

Ready for the next step?

Free intro call, no strings attached. In 30 minutes you'll know whether and how AI can help your business.

Book a call Check eligibility