Traefik, Caddy o NGINX Proxy Manager: quale reverse proxy per pochi container Docker

Chi gestisce un VPS con quattro o cinque container Docker prima o poi si pone la stessa domanda: come faccio arrivare il traffico HTTPS ai container giusti senza riscrivere a mano un certificato ogni tre mesi? Le opzioni che si incontrano sempre sono tre: Traefik, Caddy e NGINX Proxy Manager (NPM). Fanno lo stesso lavoro — terminano il TLS e instradano le richieste — ma partono da presupposti diversi, e su un VPS piccolo la differenza si sente soprattutto nella RAM libera e nel tempo che ci si mette ad aggiungere un servizio.

Certificati automatici: chi fa cosa

Tutti e tre ottengono e rinnovano certificati Let's Encrypt in automatico, quindi su questo punto non c'è uno sconfitto. Cambia il meccanismo. Traefik usa resolver ACME configurati nel file statico e li applica per router tramite label. Caddy ha l'HTTPS automatico come comportamento di default: basta scrivere il nome del dominio nel Caddyfile, senza dichiarare nulla sul certificato, e il provvedimento parte da solo, per default Caddy fornisce e rinnova i certificati TLS per i domini, e reindirizza HTTP verso HTTPS; scrivere "example.com { reverse_proxy localhost:3000 }" abilita automaticamente HTTPS con certificati Let's Encrypt. NGINX Proxy Manager richiede invece di entrare nell'interfaccia web, inserire il dominio e spuntare la richiesta del certificato: stessa automazione finale, un passaggio manuale in più la prima volta.

Interfaccia grafica o solo file

Qui le tre strade divergono davvero. Caddy ha la configurazione più compatta con un Caddyfile o API, Nginx Proxy Manager usa un'interfaccia web appoggiata su Nginx, Traefik ha configurazione statica più provider dinamici. In pratica: con NPM si clicca, con Caddy si scrive un file di poche righe leggibile anche da chi non lo ha scritto, con Traefik si aggiungono label al blocco del container nel docker-compose.yml e il routing segue il container automaticamente quando nasce o muore. Traefik tiene i dettagli di routing accanto ai servizi a cui appartengono, un vantaggio che si nota quando si gestiscono più di un paio di container.

Quanto consumano davvero

I numeri di RAM a riposo cambiano da fonte a fonte a seconda di versione, sistema operativo e metodo di misura, quindi vanno letti come ordine di grandezza, non come valore assoluto da riportare in una scheda tecnica. La misurazione più trasparente sul metodo che abbiamo trovato è quella di Virtua Cloud, che ha usato docker stats --no-stream su un VPS da 4 vCPU e 8 GB RAM con Ubuntu 24.04, con ogni proxy a riposo e senza traffico:

Proxy	RAM a riposo (misurata)	Dimensione immagine
Traefik v3.6	~17 MB	~242 MB
Caddy 2.11	~14 MB	~88 MB
Nginx 1.28 (base, senza NPM)	~5 MB	~240 MB

I numeri vengono da docker stats --no-stream su un VPS Virtua Cloud 4 vCPU/8 GB RAM con Ubuntu 24.04, con ogni proxy a riposo senza traffico. Altre misurazioni pubblicate online riportano cifre più alte per tutti e tre, fino a 200 MB per Traefik e per NPM completo di interfaccia Node.js, segno che il consumo dipende molto da quanti router e middleware sono attivi e da quanti host sono configurati nel pannello. La costante che torna in più fonti indipendenti è l'ordine relativo: Caddy e Traefik restano leggeri finché sono pochi i siti configurati, NPM pesa di più perché sopra Nginx gira anche il backend Node.js dell'interfaccia.

Esempio minimo — Traefik

services:
 traefik:
 image: traefik:v3.6
 command:
 - "--providers.docker=true"
 - "--providers.docker.exposedbydefault=false"
 - "--entrypoints.websecure.address=:443"
 - "--certificatesresolvers.le.acme.email=tuo@dominio.it"
 - "--certificatesresolvers.le.acme.storage=/letsencrypt/acme.json"
 - "--certificatesresolvers.le.acme.httpchallenge.entrypoint=web"
 - "--entrypoints.web.address=:80"
 ports:
 - "80:80"
 - "443:443"
 volumes:
 - "/var/run/docker.sock:/var/run/docker.sock:ro"
 - "./letsencrypt:/letsencrypt"

 app:
 image: myapp:latest
 labels:
 - "traefik.enable=true"
 - "traefik.http.routers.app.rule=Host(`app.tuodominio.it`)"
 - "traefik.http.routers.app.entrypoints=websecure"
 - "traefik.http.routers.app.tls.certresolver=le"

Esempio minimo — Caddy

services:
 caddy:
 image: caddy:2-alpine
 restart: unless-stopped
 ports:
 - "80:80"
 - "443:443"
 - "443:443/udp"
 volumes:
 - ./Caddyfile:/etc/caddy/Caddyfile
 - caddy_data:/data
 - caddy_config:/config

volumes:
 caddy_data:
 caddy_config:

Caddyfile:

app.tuodominio.it {
 reverse_proxy app:3000
}

La configurazione viene caricata all'avvio e Caddy supporta un reload graduale, senza interrompere le connessioni, con "docker compose exec -w /etc/caddy caddy caddy reload", quindi aggiungere un sito non richiede riavviare il container.

Esempio minimo — NGINX Proxy Manager

services:
 app:
 image: 'jc21/nginx-proxy-manager:2.16.0'
 restart: unless-stopped
 ports:
 - '80:80'
 - '443:443'
 - '81:81'
 volumes:
 - ./data:/data
 - ./letsencrypt:/etc/letsencrypt

Il dato sulla versione dell'immagine e sulla porta 81 per l'interfaccia di amministrazione viene dalle istruzioni di setup ufficiali, dove si crea un docker-compose.yml con l'immagine 'jc21/nginx-proxy-manager:2.16.0' e le porte 80, 443 e 81 esposte. Dopo il primo avvio va creato l'utente amministratore dall'interfaccia su http://ip-del-server:81, poi ogni dominio e ogni certificato si aggiungono da lì senza toccare file.

Quale scegliere per un VPS con pochi container

Per 2-5 container su un VPS piccolo (1-2 GB di RAM) nessuno dei tre strumenti pesa abbastanza da decidere la scelta. Pesa di più l'abitudine di lavoro: se i container compaiono e spariscono spesso e si preferisce non toccare file, Traefik con le label legge la configurazione direttamente dal docker-compose.yml. Se si preferisce un file di testo corto, versionabile in git, senza interfaccia da aprire, Caddy è l'opzione più diretta. Se non si vuole scrivere nulla a mano e si accetta un'interfaccia web in più da tenere aggiornata, NGINX Proxy Manager resta la via più immediata per chi parte da zero.