¿Por qué Server Manager usa Caddy?

Server Manager tiene una postura clara: todas las recetas y asistentes escriben bloques de Caddyfile, no server { } de nginx, ni <VirtualHost> de Apache, ni labels de Docker para Traefik. No es porque los otros motores sean malos: nginx, en particular, es un software excelente. Es porque Caddy reduce a cero la configuración de la parte más dolorosa de administrar un sitio web (HTTPS), y los demás no. Si ya usas nginx, Apache o Traefik, Server Manager detecta tu configuración y tú eliges: quedarte como estás (con una pequeña concesión en la experiencia de uso) o ejecutar la receta de un clic Migrar a Caddy.

¿Qué hace un proxy inverso, otra vez?

El proxy inverso es el servidor público en los puertos 80 (HTTP) y 443 (HTTPS). Los navegadores llegan a él; él reenvía cada solicitud a la app interna correcta que hay detrás: tu WordPress, tu aplicación web, tu API. Tus apps escuchan en puertos internos como 3000 o 127.0.0.1:8080; el proxy inverso es la puerta de entrada que decide qué se enruta a dónde.

Necesitas un proxy inverso para:

• Servir HTTPS (el icono del candado). Hoy en día los navegadores se niegan a enviar cookies, contraseñas o pagos por HTTP sin cifrar.
• Ejecutar varios sitios en un solo servidor con dominios distintos.
• Ocultar puertos internos: los visitantes entran en https://mysite.com, no en https://mysite.com:3000.

Las cuatro opciones habituales

La misma idea, en una línea cada uno:

• Caddy — “Quiero que HTTPS simplemente funcione.”
• nginx — “Necesito la máxima capacidad de procesamiento y tengo tiempo para configurarlo con cuidado.”
• Apache — “Ejecuto apps PHP empresariales con .htaccess.”
• Traefik — “Todo está en Docker; ponle una label.”

Por qué Server Manager eligió Caddy

Tres motivos, por orden de prioridad:

1. El HTTPS automático es la función clave para usuarios no técnicos. La mayor fuente de fricción al desplegar un sitio web pequeño es lidiar con certificados TLS. Caddy elimina esa fricción por completo. El asistente te pide que escribas un dominio; 30 segundos después, el sitio está publicado en HTTPS con un certificado válido de Let's Encrypt. Sin instalar certbot, sin elegir plugins, sin cron de renovación, sin editar configuración. Es una ventaja clarísima y no queremos renunciar a ella.
2. Unos valores predeterminados sensatos reducen los errores que rompen sitios. Caddy viene con compresión gzip, HTTP/2, cifrados TLS modernos y timeouts razonables, todo activado de forma predeterminada. nginx y Apache dejan la mayoría de estas cosas desactivadas, lo que significa que una parte real de cada despliegue con nginx acaba con una configuración sutilmente peor de lo ideal sin que el usuario siquiera sepa que debe corregirla. Caddy hace que lo correcto sea lo predeterminado.
3. La sintaxis de Caddyfile es accesible. Faro puede escribir bloques de Caddyfile de forma fiable; tú puedes leerlos. El equivalente en nginx requiere bloques multilínea como server { listen 80; listen 443 ssl; ssl_certificate /etc/letsencrypt/live/...; ... }, más difíciles de revisar de un vistazo y más difíciles de generar con precisión para un LLM. Sintaxis con menos fricción = menos errores del agente + revisiones de aprobación más claras.

Qué pierdes al elegir Caddy

Intentamos ser honestos con las concesiones. Caddy no es estrictamente mejor en todo.

• Máximo rendimiento con millones de solicitudes. nginx sigue teniendo ventaja en capacidad de procesamiento. Para la mayoría de sitios web esto no importa: el cuello de botella es tu backend, no el proxy. Pero si sirves cientos de millones de solicitudes al día, nginx usará algo menos de CPU.
• Módulos específicos de nginx. mod_lua / OpenResty, proxy_cache_path, limit_req_zone, geoip: son funciones reales que Caddy o bien resuelve de otra forma o directamente no tiene. Si dependes de ellas, migrar no es cuestión de un clic.
• **Legado de Apache + mod_php.** Algunas apps PHP antiguas asumen Apache con mod_php (PHP se ejecuta dentro del proceso de Apache). Caddy usa PHP-FPM (un proceso separado); el resultado funcional es el mismo, pero si tienes años de configuración específica de Apache (.htaccess personalizado, cadenas de mod_rewrite), adaptarlo requiere trabajo.
• Familiaridad del equipo actual. Si tu equipo ya domina nginx al detalle, cambiar tiene un coste de aprendizaje. Merece la pena por el HTTPS automático, pero no es gratis.

Para el público objetivo de Server Manager (equipos pequeños, proyectos personales, despliegues en un solo servidor), normalmente nada de esto supone un problema. La ventaja del HTTPS automático es lo que importa en el día a día.

¿Y si mantengo mi motor actual?

Puedes hacerlo. Server Manager detecta nginx, Apache y Traefik, y te ofrece dos caminos compatibles:

• Quedarte con tu motor actual. Faro lo configura de forma nativa en el chat: /etc/nginx/sites-available/ + certbot --nginx para nginx, el equivalente de Apache para Apache, y labels de Docker para Traefik. El resultado final es el mismo para cada dominio; la paleta de recetas marca los flujos solo para Caddy con una insignia 💬 por chat: siguen funcionando, solo requieren un clic de aprobación adicional frente al camino ideal con Caddy.
• **Migrar a Caddy** con la receta integrada. Traduce tu configuración existente a un Caddyfile, ensaya en puertos alternativos mientras tu motor actual sigue sirviendo tráfico real, hace el cambio de forma atómica si todo va bien y revierte automáticamente ante cualquier fallo. ~10 minutos; compatible con nginx, Apache y Traefik.

Elijas lo que elijas, tus sitios existentes siguen sirviendo tráfico. La migración es opcional.

Cuándo NO migrar

No migres a Caddy si se da cualquiera de estos casos:

• Usas OpenResty / nginx-lua u otras funciones de nginx que dependen mucho de módulos personalizados.
• Tienes reglas **Apache .htaccess complejas** con cadenas apiladas de RewriteRule [L,PT,NE].
• Ejecutas Traefik con middlewares personalizados (autenticación básica, límite de tasa, cadenas de reescritura de headers): en teoría se puede traducir, pero la receta v1 no lo hace automáticamente.
• Eres un proveedor de hosting compartido con usuarios en los que no confías: puede que dependas de los modelos de aislamiento por usuario de mod_php de Apache, que Caddy no replica.

La comprobación de gestionabilidad de la receta de migración se niega a ejecutarse cuando detecta estos casos. Pero eso solo afecta a la receta de migración automática: todas las demás acciones de Server Manager (desplegar, instalar WordPress, conectar un dominio, gestionar copias de seguridad, depurar un sitio lento, reiniciar un servicio) siguen funcionando por la vía del chat con tu motor actual. Faro se adapta al proxy que haya en el servidor. Prueba cosas; si un botón de la interfaz está bloqueado, Faro te ofrecerá hacer el mismo trabajo mediante comandos de shell.

En resumen

Caddy no es superior en todas las dimensiones. Es superior en la dimensión que más importa para el tipo de servidor que ejecuta la mayoría de usuarios de Server Manager: HTTPS automático, fiable y sin configuración. Todo lo demás (valores predeterminados sensatos, un solo binario, sintaxis concisa, recarga en vivo) refuerza esa ventaja principal.

Si ya usas nginx / Apache / Traefik y tu configuración actual funciona bien, la vía del chat está totalmente admitida. Si quieres la experiencia completa de Server Manager con un solo clic, la receta Migrar a Caddy está a un botón de distancia en la pestaña Servidor web de Información del servidor.