Caddy: la alternativa a nginx con HTTPS automático
Si alguna vez levantaste un servicio en tu homelab y quisiste ponerle un dominio con HTTPS, ya conocés el ritual: instalás nginx, escribís el reverse proxy, sumás certbot, pedís el certificado a Let’s Encrypt y armás un cron para renovar. Caddy es la alternativa a nginx para HTTPS automático que borra todos esos pasos: configurás una vez y no lo tocás nunca más.
Caddy es un servidor web open source escrito en Go que trae el flujo ACME completo incorporado. Pide, instala y renueva automáticamente los certificados TLS, redirige el puerto 80 al 443 y aplica configuración TLS moderna por defecto. No necesitás certbot aparte ni un cron de renovación. Con tres líneas en un Caddyfile ya tenés un sitio servido por HTTPS válido.
En 30 segundos
- El problema: nginx + certbot rompe cuando el path del cron está mal o el modo webroot pelea con tu config, y te enterás el día que el certificado expira.
- La solución: Caddy maneja ACME nativo, renueva antes del vencimiento y redirige 80→443 sin que escribas una sola regla.
- El truco real: con validación DNS-01 le das certificados a servicios internos que nunca exponés a internet.
- Wildcard: un solo certificado
*.lab.example.comcubre grafana, NAS y lo que sumes después, sin re-emitir. - El límite: Let’s Encrypt permite 50 certificados por semana por dominio registrado, suficiente para cualquier homelab.
Cloudflare es un servicio de red de distribución de contenidos (CDN) y seguridad web fundado en 2010, que ofrece aceleración de sitios, protección contra DDoS, DNS gestionado y certificados HTTPS. Actúa como intermediario entre usuarios finales y servidores de origen para optimizar rendimiento y seguridad.
¿Por qué nginx + certbot falla en la renovación automática?
Ponele que configuraste todo hace tres meses. Funcionaba. Hoy entrás al servicio y te encontrás con la pantalla roja de certificado vencido.
¿Qué pasó? Casi siempre lo mismo. El cron de renovación apuntaba a un path que cambió, o certbot en modo webroot estaba escribiendo el desafío en una carpeta que tu config de nginx no exponía, así que Let’s Encrypt nunca pudo validar el dominio y la renovación falló en silencio durante semanas hasta que el certificado simplemente caducó. El autor del post original en dev.to (publicado el 22 de junio de 2026) cuenta que recién a la tercera vez que pasó por esto decidió tirar todo el stack a la basura.
El tema es que nginx puede hacer todo esto. Pero te obliga a ensamblar cada pieza a mano: el script que pide el certificado, el cron que renueva, las reglas de redirección, el tuning de TLS. Cada pieza es un punto donde algo se rompe sin avisarte. Más contexto en gestionar tus certificados de forma centralizada.
¿Qué hace distinto a Caddy en la gestión de HTTPS?
Acá viene lo bueno: el flujo ACME entero vive adentro de Caddy. No hay certbot separado ni cron de renovación. Un Caddyfile completo puede ser esto:
tuservicio.example.com {
reverse_proxy localhost:8080
}Al arrancar, Caddy realiza automáticamente varias cosas. Pide el certificado a Let’s Encrypt, lo guarda localmente, lo renueva antes de que expire y redirige el puerto 80 al 443 con TLS moderno. Lo que borrás frente a nginx + certbot es el script de emisión, el cron, las reglas de redirección y el ajuste de TLS.
Caddy es la alternativa a nginx para HTTPS automático porque trae “los defaults correctos” de fábrica en vez de dejártelos armar a vos. Esa es la diferencia de fondo.
HTTP-01 vs DNS-01: ¿cuál validación te conviene?
El ejemplo de arriba usa validación HTTP-01. Let’s Encrypt te llama al puerto 80 para confirmar que controlás el dominio. Funciona bárbaro si el servicio mira a internet. ¿Y si el servicio es interno y nunca lo exponés? Ahí HTTP-01 no sirve, porque Let’s Encrypt no puede llegar a tu puerto 80. Tema relacionado: almacenar tus backups de certificados.
Para eso está DNS-01. En vez de tocar tu puerto, Let’s Encrypt te pide que pongas un registro TXT en tu DNS. Caddy lo crea solo vía la API de tu proveedor (Cloudflare, por ejemplo), demuestra que controlás el dominio y obtiene el certificado sin abrir nada hacia afuera.
| Criterio | HTTP-01 | DNS-01 |
|---|---|---|
| Cómo valida | Llamada al puerto 80 | Registro TXT en tu DNS |
| Servicios internos | No | Sí |
| Certificados wildcard | No | Sí |
| Requiere | Puerto 80 público | API token del DNS |
| Caso típico | Sitio público | Homelab, servicios internos |
¿Cómo configurar Caddy con DNS-01 para servicios internos?
El paso a paso es corto. Primero generás un API token en tu proveedor de DNS con permiso para editar registros de la zona. Después se lo pasás a Caddy en el Caddyfile:
*.lab.example.com {
tls {
dns cloudflare {env.CF_API_TOKEN}
}
@grafana host grafana.lab.example.com
handle @grafana {
reverse_proxy localhost:3000
}
@nas host nas.lab.example.com
handle @nas {
reverse_proxy localhost:5000
}
}Ojo con un detalle: el binario oficial de Caddy no trae los plugins de DNS adentro. Para Cloudflare, Route53 u otro proveedor necesitás compilar con xcaddy o bajar un build que ya incluya el módulo. Es un paso de cinco minutos, pero si no lo hacés, la directiva dns te tira error al arrancar.
¿Por qué un solo certificado wildcard para todos tus subdominios?
Un certificado *.lab.example.com cubre grafana.lab.example.com, nas.lab.example.com y cualquier servicio que sumes mañana. No tenés que pedir un certificado nuevo cada vez que levantás algo. Sumás el bloque al Caddyfile, recargás y listo. Complementá con automatizar la renovación de certificados.
El límite es que el wildcard cubre un solo nivel de subdominio. *.lab.example.com no cubre app.interno.lab.example.com. Para eso necesitás otro wildcard.
Seguridad y límites de Let’s Encrypt que conviene saber
El token de DNS tiene que ser de alcance mínimo. Dale permiso para editar registros TXT de tu zona, nada más. Si filtrás un token con acceso total a tu cuenta de DNS, el problema es bastante peor que un certificado vencido.
Algunos puntos prácticos para no comerte un dolor de cabeza:
- Límite de emisión: Let’s Encrypt permite hasta 50 certificados por semana por dominio registrado. En un homelab no lo vas a tocar, pero si automatizás emisiones en loop, mirá el contador.
- Persistencia en Docker: montá un volumen en
/data(o/root/.local/share/caddysegún la imagen) para que los certificados sobrevivan a reinicios del contenedor. Si no, Caddy los re-emite cada vez y ahí sí chocás con el límite. - WebSocket y gRPC: el
reverse_proxyde Caddy ya pasa los headers de upgrade, así que apps con WebSocket funcionan sin config extra.
Si en vez de un homelab estás montando esto sobre un VPS para servicios reales, conviene que la infraestructura de base sea sólida. Para hosting y dominios en Argentina, donweb.com es una opción local.
Casos reales: homelab, equipos chicos y proyectos en Docker
El caso más típico es el homelab con monitoring. Tenés Grafana, un NAS, un Pi-hole, tres o cuatro servicios más. Con DNS-01 y un wildcard, todos quedan detrás de HTTPS válido sin exponer nada a internet.
El segundo caso es el equipo chico con tooling interno: un panel de despliegues, un wiki, un gestor de tareas que usan cuatro personas. Es justamente la situación donde Caddy brilla: configurás una vez y te olvidás. Para más detalles técnicos, mirá orquestar tus deployments automáticamente.
Errores comunes al migrar a Caddy
- Usar el binario oficial esperando que tenga el plugin DNS: no lo trae. Compilá con
xcaddyo bajá un build con el módulo de tu proveedor incluido. - No persistir
/dataen Docker: Caddy re-emite certificados en cada reinicio y te acercás al límite semanal de Let’s Encrypt sin darte cuenta. - Darle al token de DNS más permisos de los necesarios: alcanza con editar registros TXT de tu zona. Un token con acceso total es un riesgo innecesario.
- Intentar DNS-01 sin propagación: si tu DNS tarda en propagar el TXT, la validación puede fallar el primer intento. Caddy reintenta, pero si usás un proveedor lento, dale margen.
Preguntas Frecuentes
¿Cuáles son las ventajas de Caddy sobre nginx?
Caddy trae HTTPS automático con ACME integrado, renovación nativa y redirección 80→443 por defecto. Con nginx tenés que sumar certbot, escribir las reglas de redirección y armar un cron de renovación a mano. Caddy hace en tres líneas lo que en nginx son varios archivos separados.
¿Qué es DNS-01 y por qué da certificados a servicios internos?
DNS-01 es un método de validación de Let’s Encrypt que confirma el control del dominio mediante un registro TXT en tu DNS, en vez de un llamado al puerto 80. Como no necesita que el servicio sea accesible desde internet, podés emitir certificados para servicios internos que nunca exponés.
¿Cómo evitar que expiren los certificados SSL en self-hosting?
Usá un servidor que renueve solo, como Caddy, que pide el certificado nuevo antes del vencimiento sin intervención. El error clásico con certbot es un cron mal configurado que falla en silencio. Con renovación nativa eliminás ese punto de falla.
¿Cuánto cuesta usar Caddy?
Caddy es open source y gratis, igual que los certificados de Let’s Encrypt. No pagás licencia ni por los certificados. El único costo es el del servidor o VPS donde lo corrés.
¿Por qué falla la renovación con certbot y cron?
La causa más frecuente es un path incorrecto en el cron o un conflicto entre el modo webroot de certbot y la config de nginx, que impide a Let’s Encrypt validar el dominio. La renovación falla sin alertar y te enterás el día que el certificado caduca.
Conclusión
Si tu self-hosting vive con el miedo latente al certificado que expira sin aviso, Caddy te saca ese peso de encima. El cambio concreto es pasar de ensamblar cuatro piezas frágiles (script, cron, redirección, TLS) a un Caddyfile de pocas líneas que se mantiene solo.
¿Por dónde empezar? Si tus servicios son públicos, HTTP-01 ya te alcanza. Si tenés un homelab con servicios internos, andá directo a DNS-01 con un wildcard: emitís un certificado que cubre todo y sumás servicios sin volver a tocar la emisión. Configurás una vez. No lo tocás más.
