Migra da nginx, Apache o Traefik a Caddy

Una ricetta con un clic che traduce la configurazione del tuo reverse proxy esistente in un Caddyfile, fa una prova su porte alternative mentre il vecchio motore continua a servire il traffico live, poi effettua lo scambio in modo atomico. Se una verifica fallisce, parte il rollback automatico. Dopo la migrazione, ogni flusso di Server Manager (distribuzione, collegamento di un dominio, installazione di WordPress, …) funziona direttamente, senza passare dal ripiego via chat.

Ultimo aggiornamento 26 mag 2026

Server Manager ha una preferenza netta per : ogni ricetta e procedura guidata scrive blocchi , non nginx server { }, Apache <VirtualHost> o etichette Docker di Traefik. Se il tuo server al momento usa uno di questi motori, le ricette che devono modificare la configurazione del proxy passano a un percorso 💬 via chat: funzionano comunque, ma devi approvare un passaggio in più per ogni azione. La ricetta Migra a Caddy ti porta da questa situazione a un server Caddy completamente gestito in circa 10 minuti, con una fase di prova che consente a Faro di verificare che ogni sito venga tradotto correttamente prima di qualsiasi scambio reale.

La ricetta gestisce tre motori di origine: nginx, Apache (sia apache2 su Debian/Ubuntu sia httpd su RHEL/Fedora) e Traefik (provider con etichette Docker). La struttura della migrazione è la stessa per tutti e tre: cambiano solo i dettagli lato sorgente.

1. Apri Info server → Server web

Nella barra in alto, fai clic sul nome del server per aprire il , poi fai clic sulla scheda ****.

Pannello Info server con la scheda Server web aperta, che mostra nginx come motore corrente e un pulsante Migra a Caddy

La scheda mostra:

Motore — cosa è in esecuzione sulle porte 80 / 443 in questo momento (nginx / Apache / Traefik / Caddy / nessuno).
Vhost rilevati — quanti siti sta servendo il motore (Traefik mostra invece i "router").
Certificati TLS — chi gestisce i tuoi certificati HTTPS (in genere certbot per nginx/Apache, l'ACME integrato di Traefik per Traefik).
Gestibilità — un controllo di traducibilità: un ✓ verde significa che tutti i siti usano direttive che la ricetta sa convertire; una ✗ rossa ti indica quale direttiva blocca la migrazione (mod_lua, proxy_cache_path, catene complesse di RewriteRule, middleware Traefik e così via). Se incontri una ✗ rossa, la ricetta si rifiuta di partire finché non rimuovi la direttiva non supportata: è voluto, la ricetta non elimina mai funzionalità in silenzio.

2. Fai clic su Migra a Caddy

Fai clic sul pulsante Migra questo server a Caddy →. Server Manager apre il pannello della chat e da lì Faro prende il controllo.

Dettaglio della scheda Server web: il pulsante Migra questo server a Caddy è la CTA contrassegnata come distruttiva sotto il controllo di gestibilità

La ricetta viene eseguita in 5 fasi. La fase 0 è in sola lettura (solo un passaggio di verifica). Le fasi 1–4 si fermano ciascuna per chiederti approvazione prima di eseguire qualsiasi comando distruttivo. Puoi annullare in qualsiasi momento: fino allo scambio atomico della fase 4, il motore esistente resta proprietario delle porte live e i tuoi siti continuano a servire traffico senza modifiche.

3. Approva ogni fase

Prima di ogni approvazione, Faro ti spiega cosa sta per succedere. I blocchi sono brevi e mirati.

Fase 0 — Pre-flight. Sola lettura: elenca i vhost esistenti, controlla le direttive non supportate, trova l'email amministrativa di Let's Encrypt. Si conclude con un piano in linguaggio naturale + un pulsante Reply: go. Fai clic sul pulsante (oppure digita go) per iniziare.
Fase 1 — Installa Caddy. Aggiunge il repository ufficiale di Caddy, installa il pacchetto e ferma subito il servizio. Il motore esistente resta proprietario delle porte.
Fase 2 — Traduci. Scrive un Caddyfile candidato in /tmp e lo valida. Non cambia ancora nulla in produzione.
Fase 3 — Prova. Avvia Caddy su porte alternative :8080 / :8443, così può essere testato senza toccare il traffico reale. Faro poi esegue da solo test curl in loopback (HTTPS, redirect HTTP→HTTPS, rotta della challenge ACME) e ti mostra le prove di risposta per dominio. Il motore esistente continua a servire le vere :80 / :443.

Prove della fase 3: riepilogo in linguaggio naturale di Faro, dominio per dominio, dei risultati di curl in loopback, che termina con "prova superata — pronto per lo scambio della fase 4"

Fase 4 — Scambio atomico. Esegue il backup della configurazione esistente (/etc/nginx.helm-backup.<timestamp>/ oppure /etc/apache2.helm-backup.<timestamp>/ oppure /tmp/traefik.helm-backup.compose.*.yml), ferma il vecchio motore, avvia Caddy sulle porte reali :80 / :443, verifica ogni dominio con un altro passaggio curl, poi sposta il tuo certbot.timer dalla modalità di rinnovo con plugin del motore (certbot --nginx, certbot --apache) alla modalità webroot servita da Caddy. certbot.timer continua a gestire il rinnovo; un deploy-hook ricarica Caddy a ogni rinnovo, quindi non devi mai intervenire manualmente.

Se la verifica fallisce in qualsiasi punto della fase 4, la ricetta esegue automaticamente il rollback: ferma Caddy, riavvia il vecchio motore e lascia intatta la configurazione esistente. Torni allo stato precedente alla migrazione in meno di 10 secondi.

4. Conferma + passaggio di consegne

Dopo il completamento della fase 4, Faro ti chiede di aprire ancora una volta Info server → Server web per confermare.

Scheda Server web dopo la migrazione: il motore mostra Caddy (servizio host), TLS mostra "certbot (Let's Encrypt, renewed by certbot.timer; served by Caddy via deploy-hook reload)", lo stato mostra il ✓ verde end-to-end

La scheda si aggiorna da sola all'apertura (non serve disconnettersi e riconnettersi). Dovresti vedere:

Motore: Caddy (servizio host)
Certificati TLS — per le migrazioni da nginx/Apache: certbot (Let's Encrypt, renewed by certbot.timer; served by Caddy via deploy-hook reload). Per le migrazioni da Traefik: Caddy ACME (automatic Let's Encrypt) — i vecchi certificati acme.json di Traefik non vengono riutilizzati; Caddy ne ottiene di nuovi durante il passaggio.
Stato: ✓ Server Manager gestisce questo server dall'inizio alla fine. Ogni ricetta e procedura guidata funziona direttamente; nulla passa al ripiego solo via chat.

Il pacchetto del vecchio motore resta installato (ma disabilitato) per circa 30 giorni come opzione di rollback manuale. Anche il backup della configurazione resta su disco. Quando sei sicuro che la migrazione sia stabile (circa 1 settimana), puoi usare apt remove nginx / apt remove apache2 per liberare qualche MB, oppure fermare il vecchio container Traefik con docker rm traefik.

Note per motore

La struttura prova-poi-scambia è la stessa per tutti i motori. Le differenze sono meccaniche:

nginx. Rilevamento del motore sorgente tramite sudo nginx -T. Backup in /etc/nginx.helm-backup.<ts>/. Passaggio dei rinnovi: authenticator = nginx → authenticator = webroot in /etc/letsencrypt/renewal/<domain>.conf. Il plugin certbot --nginx smette di essere usato; certbot.timer continua a funzionare.

Apache. Stessa struttura, con percorsi sostituiti per apache2 (Debian) o httpd (RHEL). Enumerazione dei vhost tramite apache2ctl -S + lettura di sites-enabled/ (o conf.d/ su RHEL). Backup in /etc/apache2.helm-backup.<ts>/. Passaggio dei rinnovi: authenticator = apache → webroot. Le configurazioni mod_php vengono contrassegnate come non gestibili finché non le rimuovi: Caddy non esegue PHP in-process come fa Apache + mod_php.

Traefik. Il motore sorgente è un container Docker, fermato con docker stop traefik (non systemctl stop). I vhost arrivano dalle etichette traefik.http.routers.* sui container in esecuzione, non da file di configurazione. Il riuso dei certificati viene saltato: Caddy ottiene certificati Let's Encrypt nuovi tramite auto-HTTPS durante il passaggio, con una nuova emissione per dominio (finestra certificato di circa 30–60 secondi). I router con middleware personalizzati o matcher non Host() vengono contrassegnati come non gestibili. I backend devono avere porte pubblicate sull'host (per esempio 127.0.0.1:8080:80 nel file compose): Caddy, essendo un servizio host, non può raggiungere container accessibili solo sulla rete Docker.

Cosa succede se la ricetta si rifiuta?

Se il controllo di gestibilità mostra una ✗ rossa, Faro indica la direttiva e il vhost esatti. Correzioni tipiche:

**nginx proxy_cache_path / fastcgi_cache** — non si traducono 1:1 in Caddy. Rimuovi la zona di cache (oppure sposta la cache su una CDN come Cloudflare) e riprova. La maggior parte degli utenti non-Caddy su server piccoli non ha bisogno di cache sul server.
**Apache RewriteRule ... [L,R=301]** — i gruppi di flag indicano catene a più passaggi che il traduttore non riesce a modellare. Convertile in un Redirect permanent più semplice, oppure appiattisci prima la catena.
Middleware Traefik — i middleware richiedono una traduzione Caddy specifica per tipo che la ricetta non esegue automaticamente nella v1. Rimuovi le etichette middleware e applica l'equivalente in Caddy dopo la migrazione (basic auth, rate limit, header: sono tutti supportati, solo non tradotti automaticamente).
**Regola Traefik HostRegexp** — i matcher regex non sono traducibili 1:1. Passa a una o più regole Host() con nomi host espliciti.

Se non riesci a semplificare la configurazione e non vuoi migrare, il percorso via chat continua a funzionare per tutto ciò che Server Manager farebbe normalmente tramite ricette: distribuire un sito, installare WordPress, collegare un dominio, configurare un database, creare un backup, ripristinarne uno e così via. Faro legge il motore esistente e propone i comandi nativi corretti (/etc/nginx/sites-available/ + certbot --nginx per nginx, l'equivalente Apache, etichette Docker per Traefik). Esempi concreti di richieste che funzionano già oggi su un server non-Caddy:

"Aggiungi un nuovo sito WordPress su blog.mysite.com su questo server nginx" — Faro propone il vhost nginx + il docker compose per WordPress + certbot. Approvi ogni blocco.
"Il mio certificato TLS per api.mysite.com sta per scadere: controllalo e rinnovalo se serve" — Faro esegue ispezione + rinnovo + reload, tutto in chat.
"Crea un backup del workload api.mysite.com" — Faro capisce cosa esportare + come impacchettarlo + offre il link di download.

Non perdi funzionalità restando sul motore attuale. Scambi le scorciatoie dell'interfaccia a un clic con equivalenti mediati dalla chat.

Riferimento

File scritti sul tuo server durante la migrazione:

/etc/caddy/Caddyfile — configurazione dei siti di Caddy (nuova su questo server)
/var/www/certbot/.well-known/acme-challenge/ — webroot per i rinnovi ACME (nginx + Apache; non usato per le migrazioni da Traefik)
/etc/letsencrypt/renewal-hooks/deploy/reload-caddy.sh — ricarica Caddy a ogni rinnovo certbot (solo nginx + Apache)
/etc/letsencrypt/renewal/<domain>.conf — modificato in modo chirurgico per sostituire authenticator = nginx / authenticator = apache → authenticator = webroot (solo nginx + Apache)

File / stato conservati per il rollback:

nginx: /etc/nginx.helm-backup.<timestamp>/ (copia completa della configurazione)
Apache: /etc/apache2.helm-backup.<timestamp>/ (Debian) o /etc/httpd.helm-backup.<timestamp>/ (RHEL)
Traefik: /tmp/traefik.helm-backup.compose.<timestamp>.yml (il file docker-compose), più il container Traefik fermato
Il pacchetto del vecchio motore resta installato ma disabilitato (systemctl disable apache2 / nginx; docker update --restart=no traefik)

Punti di approvazione: in genere 4 clic per nginx e Apache, 5 per Traefik (quello in più serve quando Faro deve scegliere una porta di prova non predefinita perché il backend usa già :8080).