Qué es Caddy: servidor web con HTTPS automático en palabras sencillas

Qué es Caddy

Caddy — un servidor web y proxy inverso que obtiene y renueva los certificados TLS para tus dominios automáticamente. Basta con indicar el nombre del sitio en la configuración, y Caddy lo abrirá por HTTPS: sin certbot, sin tareas cron y sin configuración manual del cifrado.

El proyecto está escrito en Go y se distribuye bajo la licencia Apache 2.0. La versión vigente a septiembre de 2026 es 2.11.4 (junio de 2026). Caddy se entrega como un único ejecutable sin dependencias externas; hay un repositorio oficial de paquetes para Debian y Ubuntu y una imagen Docker caddy.

Cómo funciona el HTTPS automático

Para un dominio público Caddy obtiene el certificado por sí mismo si se cumplen tres condiciones: los registros DNS A o AAAA del dominio apuntan al servidor, los puertos 80 y 443 son accesibles desde Internet, y Caddy tiene permiso para escucharlos. Por defecto se usan dos autoridades de certificación con el protocolo ACME — Let’s Encrypt y ZeroSSL: si Let’s Encrypt no emite el certificado, Caddy prueba con ZeroSSL. La renovación ocurre con antelación y sin intervención del administrador.

Los certificados y claves se almacenan en el directorio de datos de Caddy. Debe ser persistente y accesible para escritura: si el directorio se pierde, por ejemplo al recrear un contenedor sin volumen, Caddy solicita los certificados de nuevo y puede toparse con límites de la autoridad de certificación.

Para nombres que no puedan obtener un certificado público — localhost, direcciones internas — Caddy emite certificados con su propia autoridad de certificación local e intenta añadir su certificado raíz al almacén de confianza del sistema. Si no hay permisos para ello (en un contenedor o bajo un usuario sin privilegios), el certificado raíz se instala con el comando caddy trust o se copia manualmente.

Instalación

En Debian y Ubuntu Caddy se instala desde el repositorio oficial:

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo chmod o+r /usr/share/keyrings/caddy-stable-archive-keyring.gpg
sudo chmod o+r /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

Tras la instalación Caddy funciona como servicio systemd caddy, la configuración está en /etc/caddy/Caddyfile. Los cambios se aplican con sudo systemctl reload caddy sin interrumpir las conexiones actuales.

Caddyfile: proxy inverso en tres líneas

La aplicación escucha en el puerto 3000 en el mismo servidor y debe exponerse en app.example.ru:

app.example.ru {
    reverse_proxy localhost:3000
}

Eso es suficiente: Caddy obtendrá el certificado, redirigirá HTTP a HTTPS y enviará las solicitudes a la aplicación. Varios servicios se describen en bloques separados:

app.example.ru {
    reverse_proxy localhost:3000
}

api.example.ru {
    reverse_proxy localhost:8000
}

www.example.ru {
    redir https://example.ru{uri} permanent
}

Sitio estático con compresión de respuestas:

example.ru {
    root * /var/www/example
    file_server
    encode gzip zstd
}

El balanceo entre varias instancias de la aplicación se configura en la misma directiva:

app.example.ru {
    reverse_proxy 10.0.0.11:8080 10.0.0.12:8080 {
        lb_policy round_robin
        health_uri /health
    }
}

Antes de aplicar es útil comprobar la configuración con caddy validate --config /etc/caddy/Caddyfile, y normalizarla con caddy fmt.

HTTPS en desarrollo local

Para desarrollar en tu máquina usa localhost:

localhost {
    reverse_proxy localhost:3000
}

Caddy emitirá un certificado de su autoridad de certificación local, y el navegador abrirá https://localhost sin advertencias si el certificado raíz está instalado. Para nombres internos propios se añade la línea tls internal en el bloque del sitio.

No inventes para pruebas nombres en zonas públicas como app.dev: .dev es un dominio de nivel superior real, no se emitirá un certificado para un nombre ajeno, y los navegadores exigen HTTPS para toda la zona .dev.

Caddy en Docker y CI/CD

La imagen caddy es cómoda de integrar en el proyecto mediante Docker Compose: el Caddyfile se guarda en el repositorio junto con la aplicación, y el directorio de datos se coloca en un volumen nombrado para que los certificados sobrevivan a la recreación del contenedor. En el pipeline de build no hay pasos para obtener certificados: basta verificar la configuración con caddy validate y recargarla tras el despliegue.

Errores típicos

• Puerto 80 cerrado. Incluso si el sitio funciona solo por HTTPS, el puerto 80 es necesario para la verificación de dominio y la redirección. Si lo cierras con un cortafuegos, detendrás la emisión y renovación de certificados.
• DNS apunta al servidor equivocado. Mientras el registro A dirija al hosting antiguo o a una CDN, no se emitirá el certificado. Cambia el DNS primero y luego lanza Caddy.
• Directorio de datos perdido. Un contenedor sin volumen solicita los certificados de nuevo cada vez que se recrea.
• Puertos ocupados por otro servidor. Si en la máquina ya está corriendo nginx o Apache en 80 y 443, Caddy no podrá arrancar; dos servidores web no pueden usar los mismos puertos.
• Esperar que incluya protección contra todo. El rate limiting y la protección contra bots no forman parte de la compilación estándar y se añaden mediante módulos de terceros.

Cuándo elegir Caddy

Caddy es bueno cuando en un servidor necesitas publicar rápidamente varios sitios o servicios por HTTPS y no quieres gestionar certbot ni configuraciones largas. Si necesitas balanceo avanzado con comprobaciones y limitaciones o proxy TCP, mira HAProxy; si la infraestructura ya está construida sobre nginx y sus módulos — Nginx; si los servicios aparecen y desaparecen continuamente en contenedores — Traefik. Una comparación de los cinco servidores está en el artículo «Caddy vs. Traefik vs. HAProxy vs. Nginx vs. Apache».