Skip to main content

Caddy

Caddy is a modern web server and reverse proxy designed around simplicity. Its standout feature is automatic HTTPS by default—no Certbot, cron jobs, or manual TLS config.

Caddy is a strong choice for:

  • small services and personal projects
  • internal tools and dashboards
  • prototypes where you want HTTPS immediately
  • setups where minimal configuration matters more than fine-grained tuning

Install Caddy (Ubuntu / Debian)​

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -fsSL https://dl.cloudsmith.io/public/caddy/stable/gpg.key \
  | sudo tee /usr/share/keyrings/caddy-stable-archive-keyring.gpg >/dev/null
curl -fsSL https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt \
  | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install -y caddy
sudo systemctl enable --now caddy
  • Installs Caddy as a systemd service
  • Starts automatically on boot

Check status:

systemctl status caddy

Where Caddy configuration lives​

  • Config file: /etc/caddy/Caddyfile
  • Logs: journalctl -u caddy
  • Certificates: managed automatically by Caddy

You usually only touch the Caddyfile.

Basic reverse proxy (automatic HTTPS)​

Edit the Caddyfile:

sudo nano /etc/caddy/Caddyfile
example.com {
  reverse_proxy 127.0.0.1:3000
}

Apply changes:

sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy

What happens automatically:

  • HTTP → HTTPS redirect
  • TLS certificates via Let’s Encrypt
  • Certificate renewal
  • Sensible security defaults

No extra flags required.

Verify​

curl -I http://example.com
curl -I https://example.com
journalctl -u caddy -n 50 --no-pager

If DNS is correct and port 80/443 are open, HTTPS just works.

Common issues​

Certificate not issued

  • Domain does not resolve to the server
  • Ports 80/443 blocked by firewall
  • Using a local-only hostname (see below)

Local development For local-only setups, use:

localhost {
  reverse_proxy 127.0.0.1:3000
}

This uses local certificates instead of Let’s Encrypt.

When to use Caddy​

  • You want HTTPS without manual setup
  • You prefer readable, minimal configuration
  • You deploy small or medium services
  • You don’t need complex routing rules

When not to use Caddy​

  • You need very advanced traffic shaping or caching
  • You already run complex Nginx configs
  • You want a GUI-based proxy manager
  • You need tight control over TLS internals

Caddy vs Nginx (quick intuition)​

  • Caddy: defaults-first, HTTPS by default, minimal config
  • Nginx: maximum control, explicit config, mature ecosystem

Neither is “better”—they optimize for different priorities.

Key takeaways​

  • Caddy prioritizes simplicity and security by default
  • Automatic HTTPS is built in
  • Configuration is concise and readable
  • Ideal for small services and fast setups
  • Managed via systemd like other Linux services

Deploy without managing servers​

If you don’t want to manage Caddy, certificates, or configs yourself:

👉 Deploy an app with automatic HTTPS

Hostim.dev provides HTTPS, domains, logs, and metrics out of the box—no proxy configuration required.