Migrar de nginx, Apache o Traefik a Caddy

Receta de un clic que traduce tu configuración actual de proxy inverso a un Caddyfile, ensaya en puertos alternativos mientras el motor anterior sigue sirviendo el tráfico real y luego hace el cambio de forma atómica. La reversión automática se activa si falla cualquier verificación. Después de la migración, todos los flujos de Server Manager (desplegar, conectar un dominio, instalar WordPress, …) funcionan directamente en lugar de pasar por la vía de reserva del chat.

Última actualización 26 may 2026

Server Manager apuesta por : todas las recetas y asistentes escriben bloques de , no bloques nginx server { }, Apache <VirtualHost> ni etiquetas Docker de Traefik. Si tu servidor ejecuta ahora mismo uno de esos motores, las recetas que necesitan tocar la configuración del proxy pasan a una ruta 💬 por chat: siguen funcionando, pero tienes que aprobar un paso más por cada acción. La receta Migrar a Caddy te lleva desde ese estado hasta un servidor Caddy totalmente gestionado en unos 10 minutos, con un ensayo que permite a Faro comprobar que cada sitio se traduce correctamente antes de hacer ningún cambio real.

La receta admite tres motores de origen: nginx, Apache (tanto apache2 en Debian/Ubuntu como httpd en RHEL/Fedora) y Traefik (proveedor mediante etiquetas Docker). La estructura de la migración es la misma para los tres; solo cambian los detalles del motor de origen.

1. Abre Información del servidor → Servidor web

En la barra superior, haz clic en el nombre de tu servidor para abrir el y luego haz clic en la pestaña ****.

Panel de información del servidor con la pestaña Servidor web abierta, mostrando nginx como motor actual y un botón para migrar a Caddy

La pestaña muestra:

Motor: qué está escuchando ahora mismo en los puertos 80 / 443 (nginx / Apache / Traefik / Caddy / ninguno).
Vhosts detectados: cuántos sitios está sirviendo el motor (Traefik muestra "routers" en su lugar).
Certificados TLS: quién gestiona tus certificados HTTPS (normalmente certbot para nginx/Apache, o el ACME integrado de Traefik para Traefik).
Gestionabilidad: una comprobación de traducibilidad. Un ✓ verde significa que todos los sitios usan directivas que la receta sabe convertir; una ✗ roja te indica qué directiva lo impide (mod_lua, proxy_cache_path, cadenas complejas de RewriteRule, middlewares de Traefik, etc.). Si aparece una ✗ roja, la receta no se ejecuta hasta que elimines la directiva no compatible. Es intencionado: la receta nunca descarta comportamiento en silencio.

2. Haz clic en Migrar a Caddy

Haz clic en el botón Migrar este servidor a Caddy →. Server Manager abre el panel de chat y Faro toma el control a partir de ahí.

Detalle de la pestaña Servidor web: el botón Migrar este servidor a Caddy es la llamada a la acción marcada como destructiva debajo de la comprobación de gestionabilidad

La receta se ejecuta en 5 fases. La fase 0 es de solo lectura (solo una pasada de verificación). Las fases 1–4 se detienen para pedir tu aprobación antes de ejecutar cualquier comando destructivo. Puedes cancelar en cualquier momento: hasta el cambio atómico de la fase 4, tu motor actual sigue siendo dueño de los puertos reales y tus sitios continúan sirviendo tráfico sin cambios.

3. Aprueba cada fase

Faro te cuenta qué va a pasar antes de pedir cada aprobación. Los paquetes son cortos y concretos.

Fase 0 — Comprobaciones previas. Solo lectura: enumera tus vhosts actuales, comprueba directivas no compatibles y encuentra el correo de administración de Let's Encrypt. Termina con un plan en lenguaje natural y un botón Reply: go. Haz clic en él (o escribe go) para empezar.
Fase 1 — Instalar Caddy. Añade el repositorio oficial de Caddy, instala el paquete y detiene el servicio de inmediato. Tu motor actual sigue ocupando los puertos.
Fase 2 — Traducir. Escribe un Caddyfile candidato en /tmp y lo valida. Todavía no cambia nada en producción.
Fase 3 — Ensayar. Inicia Caddy en los puertos alternativos :8080 / :8443 para probarlo sin tocar el tráfico real. Luego Faro ejecuta por su cuenta pruebas curl en loopback (HTTPS, redirección HTTP→HTTPS, ruta de desafío ACME) y te muestra las evidencias de respuesta por dominio. Tu motor actual sigue sirviendo los puertos reales :80 / :443.

Evidencias de la fase 3: resumen en lenguaje natural de Faro por dominio con los resultados de curl en loopback, que termina con "ensayo superado: listo para el cambio de la fase 4"

Fase 4 — Cambio atómico. Hace una copia de seguridad de tu configuración actual (/etc/nginx.helm-backup.<timestamp>/, /etc/apache2.helm-backup.<timestamp>/ o /tmp/traefik.helm-backup.compose.*.yml), detiene el motor anterior, inicia Caddy en los puertos reales :80 / :443, verifica cada dominio con una pasada más de curl y luego cambia tu certbot.timer actual del modo de renovación con plugin del motor (certbot --nginx, certbot --apache) al modo webroot que Caddy puede servir. certbot.timer sigue encargándose de la renovación; un deploy-hook recarga Caddy en cada renovación para que no tengas que tocar nada.

Si la verificación falla en cualquier punto de la fase 4, la receta revierte automáticamente: detiene Caddy, reinicia el motor anterior y deja intacta tu configuración existente. Vuelves al estado previo a la migración en <10 segundos.

4. Confirma y entrega el control

Cuando la fase 4 termina correctamente, Faro te pide que abras Información del servidor → Servidor web una vez más para confirmarlo.

Pestaña Servidor web después de la migración: el motor muestra Caddy (servicio del host), TLS muestra "certbot (Let's Encrypt, renovado por certbot.timer; servido por Caddy mediante recarga por deploy-hook)" y el estado muestra el ✓ verde de extremo a extremo

La pestaña se actualiza sola al abrirla (no hace falta desconectar y volver a conectar). Deberías ver:

Motor: Caddy (servicio del host)
Certificados TLS: para migraciones desde nginx/Apache: certbot (Let's Encrypt, renewed by certbot.timer; served by Caddy via deploy-hook reload). Para migraciones desde Traefik: Caddy ACME (automatic Let's Encrypt). Los certificados antiguos de Traefik en acme.json no se reutilizan; Caddy obtiene certificados nuevos durante el cambio.
Estado: ✓ Server Manager gestiona este servidor de extremo a extremo. Todas las recetas y asistentes funcionan directamente; nada se desvía a la ruta de reserva solo por chat.

El paquete de tu motor anterior queda instalado (pero deshabilitado) durante unos 30 días como opción de reversión manual. La copia de seguridad de la configuración también permanece en disco. Cuando tengas claro que la migración está estable (aprox. 1 semana), puedes ejecutar apt remove nginx / apt remove apache2 para liberar unos MB, o detener el contenedor antiguo de Traefik con docker rm traefik.

Notas por motor

La estructura de ensayar y luego cambiar es la misma en todos los motores. Las diferencias son mecánicas:

nginx. Detección del motor de origen mediante sudo nginx -T. Copia de seguridad en /etc/nginx.helm-backup.<ts>/. Traspaso de renovación: authenticator = nginx → authenticator = webroot en /etc/letsencrypt/renewal/<domain>.conf. El plugin certbot --nginx deja de usarse; certbot.timer sigue ejecutándose.

Apache. Misma estructura, cambiando las rutas por apache2 (Debian) o httpd (RHEL). Enumeración de vhosts mediante apache2ctl -S y lectura de sites-enabled/ (o conf.d/ en RHEL). Copia de seguridad en /etc/apache2.helm-backup.<ts>/. Traspaso de renovación: authenticator = apache → webroot. Las configuraciones con mod_php se marcan como no gestionables hasta que las elimines: Caddy no ejecuta PHP dentro del proceso como lo hace Apache + mod_php.

Traefik. El motor de origen es un contenedor Docker, detenido con docker stop traefik (no con systemctl stop). Los vhosts salen de las etiquetas traefik.http.routers.* de los contenedores en ejecución, no de archivos de configuración. Se omite la reutilización de certificados: Caddy obtiene certificados nuevos de Let's Encrypt mediante auto-HTTPS durante el cambio, lo que supone una emisión nueva por dominio (ventana de certificado de unos 30–60 segundos). Los routers con middlewares personalizados o comparadores que no sean Host() se marcan como no gestionables. Los backends deben tener puertos publicados en el host (por ejemplo, 127.0.0.1:8080:80 en el archivo compose): Caddy, como servicio del host, no puede llegar a contenedores accesibles solo por la red Docker.

¿Y si la receta se niega?

Si la comprobación de gestionabilidad muestra una ✗ roja, Faro indica la directiva y el vhost exactos. Soluciones habituales:

**nginx proxy_cache_path / fastcgi_cache**: no se traducen 1:1 a Caddy. Elimina la zona de caché (o mueve la caché a una CDN como Cloudflare) y vuelve a intentarlo. La mayoría de usuarios de servidores pequeños que no usan Caddy no necesitan caché dentro del propio servidor.
**Apache RewriteRule ... [L,R=301]**: los paquetes de avisos indican cadenas de varios pasos que el traductor no puede modelar. Cámbialas por un Redirect permanent más sencillo o aplana la cadena previamente.
Middlewares de Traefik: los middlewares necesitan una traducción a Caddy por tipo que la receta no automatiza en la v1. Elimina las etiquetas de middleware y aplica el equivalente en Caddy después de la migración (autenticación básica, limitación de tasa, cabeceras: todo está soportado, pero no se traduce automáticamente).
**Regla HostRegexp de Traefik**: los comparadores con regex no se traducen 1:1. Cambia a una o varias reglas Host() con nombres de host explícitos.

Si no puedes simplificar tu configuración y no quieres migrar, la ruta por chat sigue funcionando para todo lo que Server Manager haría normalmente mediante recetas: desplegar un sitio, instalar WordPress, conectar un dominio, configurar una base de datos, hacer una copia de seguridad, restaurar desde una copia, etc. Faro lee tu motor actual y propone los comandos nativos adecuados (/etc/nginx/sites-available/ + certbot --nginx para nginx, el equivalente de Apache, etiquetas Docker para Traefik). Ejemplos concretos que funcionan hoy en un servidor que no usa Caddy:

"Añade un sitio WordPress nuevo en blog.mysite.com en este servidor nginx" — Faro propone el vhost de nginx, el docker compose para WordPress y certbot. Tú apruebas cada paquete.
"Mi certificado TLS para api.mysite.com está a punto de caducar: compruébalo y renuévalo si hace falta" — Faro ejecuta la inspección, la renovación y la recarga, todo en el chat.
"Haz una copia de seguridad de la carga de trabajo de api.mysite.com" — Faro averigua qué volcar y cómo empaquetarlo, y te ofrece el enlace de descarga.

No pierdes funciones por quedarte en tu motor actual. Cambias las facilidades de la interfaz de un clic por equivalentes mediados por chat.

Referencia

Archivos escritos en tu servidor durante la migración:

/etc/caddy/Caddyfile — configuración de sitios de Caddy (nueva en este servidor)
/var/www/certbot/.well-known/acme-challenge/ — webroot para renovaciones ACME (nginx + Apache; no se usa en migraciones desde Traefik)
/etc/letsencrypt/renewal-hooks/deploy/reload-caddy.sh — recarga Caddy en cada renovación de certbot (solo nginx + Apache)
/etc/letsencrypt/renewal/<domain>.conf — editado de forma quirúrgica para cambiar authenticator = nginx / authenticator = apache → authenticator = webroot (solo nginx + Apache)

Archivos / estado conservados para reversión:

nginx: /etc/nginx.helm-backup.<timestamp>/ (copia completa de la configuración)
Apache: /etc/apache2.helm-backup.<timestamp>/ (Debian) o /etc/httpd.helm-backup.<timestamp>/ (RHEL)
Traefik: /tmp/traefik.helm-backup.compose.<timestamp>.yml (el archivo docker-compose), más el propio contenedor Traefik detenido
El paquete del motor anterior permanece instalado pero deshabilitado (systemctl disable apache2 / nginx; docker update --restart=no traefik)

Puntos de aprobación: normalmente 4 clics para nginx y Apache, 5 para Traefik (el adicional aparece cuando Faro necesita elegir un puerto de ensayo no predeterminado si tu backend ya usa :8080).