Vuoi un reverse Proxy da gestire in pochi minuti? Caddy è la soluzione

Hai mai passato ore a configurare Nginx, a cercare di far funzionare certbot o a debuggare un nginx.conf con 200 righe? Caddy nasce per eliminare esattamente questo problema. È un server web e reverse proxy scritto in Go, progettato con un'unica filosofia: la sicurezza e la produttività non devono richiedere un PhD in networking.

In tre righe di configurazione ottieni un reverse proxy completo con HTTPS, HTTP/2, HTTP/3 e redirect automatico da HTTP a HTTPS. Niente altro. 

Perché Caddy batte la concorrenza (per la semplicità)

Il punto chiave: con Caddy non installi certbot, non scrivi blocchi ssl_certificate, non configuri redirect manuali. Il dominio nel Caddyfile è la configurazione TLS.

Setup in 5 minuti (Linux)

1. Installa Caddy

# Aggiungi il repository ufficiale
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
echo "deb [signed-by=/usr/share/keyrings/caddy-server-archive-keyring.gpg] https://dl.caddyserver.com/apt stable main" | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update && sudo apt install -y caddy   

2. Scrivi il Caddyfile

Apri /etc/caddy/Caddyfile e sostituisci il contenuto con:

{
    email admin@tuo-dominio.com
}

app.tuo-dominio.com {
    reverse_proxy localhost:3000
}   

È tutto. Caddy farà automaticamente:

• Ascoltare su porte 80 e 443
• Ottenere un certificato Let's Encrypt per app.tuo-dominio.com
• Redirect HTTP → HTTPS
• Proxy del traffico al backend su porta 3000
• Rinnovo del certificato prima della scadenza

3. Avvia e verifica

sudo systemctl enable --now caddy
curl -I https://app.tuo-dominio.com   

Vedrai un 200 (o il response del tuo backend) con HTTP/2 e un certificato valido.

Docker: il caso d'uso più comune

Per un homelab con servizi containerizzati, il setup è ancora più rapido:

# docker-compose.yml
services:
  caddy:
    image: caddy:alpine
    restart: always
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
      - caddy_config:/config
    networks:
      - edge

  gitea:
    image: gitea/gitea:latest
    restart: unless-stopped
    environment:
      - USER_UID=1000
      - USER_GID=1000
    volumes:
      - gitea_data:/data
    networks:
      - edge

  jellyfin:
    image: jellyfin/jellyfin:latest
    restart: unless-stopped
    networks:
      - edge

volumes:
  caddy_data:
  caddy_config:
  gitea_data:

Caddyfile:

{
    email admin@tuo-dominio.com
}

git.tuo-dominio.com {
    reverse_proxy gitea:3000
}

jellyfin.tuo-dominio.com {
    reverse_proxy jellyfin:8096
}   

docker compose up -d   

Visita https://app.tuodominio.com — funziona, con HTTPS completo.

Riavviare Caddy dopo modifiche

Dopo aver modificato il Caddyfile, le modifiche non si applicano da sole. Serve un reload:

Installazione nativa (systemd):

sudo systemctl reload caddy   

Docker Compose:

docker compose exec -w /etc/caddy caddy caddy reload   

Il reload è graceful: Caddy carica la nuova configurazione e le connessioni in corso finiscono con quella vecchia. Zero downtime. Se la nuova config ha un errore, Caddy continua a servire con quella vecchia e riporta l'errore a schermo.

Nota: non usare restart per le modifiche di configurazione — interrompe le connessioni attive. Il restart serve solo per aggiornare il binario di Caddy stesso.

E oltre il reverse proxy

Caddy non si limita a fare da proxy. Con poche righe in più nel Caddyfile puoi aggiungere:

• Header di sicurezza (HSTS, X-Frame-Options, X-Content-Type-Options) riutilizzabili via snippet
• Autenticazione basica con password hashate
• Load balancing tra più backend con health check
• WebSocket gestiti automaticamente senza configurazione extra
• Certificati wildcard tramite DNS-01 (es. Cloudflare), senza esporre le porte 80/443

Tutto senza plugin esterni: è tutto già nel binario.

Quando Caddy non è la scelta giusta

Per essere onesti: Caddy non è perfetto per ogni scenario.

• Alto traffico con requisiti di tuning fine → Nginx offre più controllo su worker process, buffering, connection pooling.
• Service discovery automatica da Docker labels → Traefik è più immediato.
• Footprint di memoria critico (es. Raspberry Pi con 512 MB) → Nginx usa ~3 MB vs ~15 MB di Caddy.

Ma per il 90% degli scenari — homelab, side project, microservizi, API gateway leggeri — Caddy è la via più rapida verso un reverse proxy sicuro, moderno e a bassa manutenzione. 

Conclusione

La promessa di Caddy è mantenuta: un reverse proxy in pochi minuti, senza certbot, senza blocchi SSL, senza redirect manuali. Un singolo binario Go, un Caddyfile leggibile, e HTTPS che funziona out of the box. Se il tuo obiettivo è esporre un servizio al mondo in modo sicuro senza diventare un sysadmin, Caddy è la soluzione.