Caddy 2.11 en pymes: HTTPS, proxy y logs
Guía técnica para decidir Caddy 2.11 como proxy reverso: certificados, rutas, permisos, logs, costos y prueba de caída.
Un proxy reverso recibe una URL pública, elige un servicio interno y deja un rastro de cada respuesta. Caddy 2.11 suma HTTPS automático, proxy configurable y logs de acceso en un archivo claro. Para una pyme con Odoo, Nextcloud o un portal propio, la decisión técnica empieza por dominio, certificado, ruta, permiso y prueba de caída. Esta guía muestra qué se instala y qué se prueba primero.
Dónde aparece el costo de publicar un servicio
El costo aparece cuando cada aplicación resuelve HTTPS, certificados y logs por su cuenta. Un portal de turnos, un ERP y un tablero interno pueden vivir en servidores distintos, aunque el usuario solo vea tres dominios. Caddy concentra esa entrada y evita que cada equipo repita certificados, puertos y reglas de firewall con criterios separados.
La cifra que ubica el tema viene del propio proyecto: Caddy 2.11.3 fue publicado el 12 de mayo de 2026 con más de cien artefactos de descarga. En paralelo, GitHub informó en Octoverse 2025 que más de 180 millones de desarrolladores trabajan en la plataforma y se crean cerca de 230 repositorios por minuto. Esa escala explica por qué las pymes adoptan piezas abiertas, aunque después necesiten reglas locales para producción.
Un certificado vencido también es una interrupción de ventas.
El problema concreto era el archivo nginx.conf heredado de un proveedor anterior. En una municipalidad chica del Gran Mendoza, sistemas tenía rutas copiadas de tres años, comentarios viejos y un dominio de prueba todavía activo. El detalle visible era una etiqueta amarilla pegada al frente del gabinete: "web vieja". La etiqueta decía dónde enchufar. El dominio vivo seguía sin dueño escrito.
Cómo funciona por dentro
El flujo empieza en DNS. El dominio apunta al servidor que corre Caddy. Caddy escucha en 80 y 443, pide o renueva certificados, redirige tráfico HTTP a HTTPS y aplica reglas por host. La directiva reverse_proxy recibe la petición y la manda al servicio interno correcto: Odoo, Nextcloud, una API o un sitio estático.
Los datos de negocio quedan en PostgreSQL: facturas, turnos, usuarios o auditoría de cada aplicación. El proxy guarda configuración, certificados, logs de acceso y errores. La directiva log define qué solicitudes quedan registradas, con qué formato y en qué archivo. Esa salida alimenta monitoreo o una revisión posterior.
Los permisos separan edición y lectura. Sistemas edita el Caddyfile y reinicia el servicio. Soporte lee logs acotados para diagnosticar 404, 502 o errores de certificado. Dirección recibe un tablero de disponibilidad. El backup copia Caddyfile, certificados administrados, logs rotados y documentación de dominios; la restauración levanta un servidor nuevo y prueba que cada dominio responda con el certificado esperado.
Qué se instala o configura primero
La pila mínima usa Caddy 2.11, systemd, un firewall con puertos 80/443, DNS administrado, Prometheus node exporter o Uptime Kuma para chequeos y Restic para copia de configuración. Un servidor virtual chico cuesta de USD 12 a USD 35 mensuales, entre ARS 17.184 y ARS 50.120 al dólar vendedor de ARS 1432. El costo incluye cómputo y disco. La migración de aplicaciones y la corrección de URLs absolutas se estiman aparte.
El primer entregable verificable es una tabla de dominios con destino, dueño, certificado, estado y prueba. La segunda entrega es un Caddyfile comentado con tres rutas reales y un log por sitio. En despliegues UMSA, la prueba inicial usa un dominio temporal, un servicio de demo y una caída simulada para comprobar que el 502 aparece en el log y en la alerta.
La implementación toma de una a tres semanas. Si los dominios están ordenados, Caddy entra rápido. Si cada aplicación trae su propio proxy interno, la primera tarea es listar puertos, cabeceras y URLs públicas. La diferencia se ve cuando una renovación de certificado deja de depender de un recordatorio en calendario. El registro de cambios queda en Git privado, con revisión de pares para cada dominio nuevo y cada ruta removida.
Dónde se rompe y cómo probarlo
El primer riesgo es apuntar el dominio al servicio equivocado. La señal aparece como 200 correcto en el proxy y contenido incorrecto para el usuario. La prueba carga una URL de salud por aplicación y compara host, cabecera y respuesta esperada.
El segundo riesgo es ocultar la IP real. La señal aparece cuando la aplicación registra siempre la dirección del proxy. La prueba revisa cabeceras, logs y reglas de confianza antes de abrir el servicio a internet.
El tercer riesgo es perder certificados o configuración. La señal aparece cuando un servidor nuevo arranca y solo responde por HTTP. La prueba restaura Caddyfile y carpeta de datos en una máquina limpia, ejecuta validación de configuración y confirma HTTPS en cada dominio.
Caddy sirve cuando la publicación web queda escrita en cuatro columnas revisables: dominio, destino, certificado y responsable.