Caddy se ha convertido en una opción habitual para publicar servicios web con HTTPS automático, configuraciones limpias y una curva de entrada más amable que la de otros servidores tradicionales. Pero cuando una infraestructura empieza a crecer, gestionar varios servidores Caddy2, revisar configuraciones, validar Caddyfiles, controlar usuarios, consultar estado y mantener auditoría puede terminar repartido entre consola, archivos, scripts y documentación interna.
CaddyManager intenta resolver esa parte operativa con una interfaz web moderna para administrar servidores Caddy2 desde un único panel. El proyecto, disponible como software libre bajo licencia MIT, está construido sobre el stack MEVN y combina frontend en Vue 3 con backend Node.js y Express. Su objetivo no es sustituir a Caddy, sino facilitar la gestión diaria de múltiples instancias, configuraciones, usuarios, claves API, métricas y registros de auditoría.
Conviene leerlo con una cautela importante: el propio proyecto avisa de que está en desarrollo temprano y recomienda hacer copia de seguridad de las configuraciones y datos de Caddy antes de probarlo. Es decir, puede ser una herramienta interesante para laboratorios, pruebas y equipos técnicos que quieran explorar una capa visual de administración, pero no debería colocarse delante de entornos críticos sin validación previa.
Gestión multi-servidor, configuración y control de acceso
La función central de CaddyManager es permitir añadir, eliminar, monitorizar y gestionar varios servidores Caddy2 desde un mismo dashboard. Para equipos que trabajan con más de una instancia, esta idea puede ahorrar bastante tiempo, sobre todo cuando se quiere comprobar estado, editar configuraciones o revisar cambios sin saltar entre máquinas.
El editor de configuración permite crear, editar y validar Caddyfiles con resaltado de sintaxis y plantillas. Esta parte es importante porque muchos errores en servidores web no vienen de grandes fallos de arquitectura, sino de cambios pequeños mal revisados: una ruta incorrecta, un bloque mal cerrado, un proxy mal definido o una directiva aplicada donde no toca. Tener validación y una interfaz común puede reducir parte de ese riesgo, aunque no elimina la necesidad de revisar bien cada despliegue.
CaddyManager también incorpora autenticación de usuarios, sesiones basadas en JWT y control de acceso por roles. Además, incluye gestión de claves API para acceso programático, con posibilidad de generar y revocar credenciales desde el panel. Esta combinación encaja con entornos donde no basta con que una sola persona tenga acceso por SSH al servidor, sino que se necesita separar permisos, registrar acciones y permitir cierta automatización.
| Área | Qué aporta CaddyManager |
|---|---|
| Gestión de servidores | Alta, baja, monitorización y control de varios servidores Caddy2 |
| Configuración | Editor de Caddyfiles con sintaxis, plantillas y validación |
| Usuarios | Login seguro, sesiones JWT y roles |
| API keys | Creación y revocación de claves para acceso programático |
| Auditoría | Registro de acciones de usuarios y del sistema |
| Estado | Health checks y actualizaciones en tiempo real |
| API | Documentación Swagger integrada |
| Métricas | Endpoints compatibles con Prometheus y salida JSON |
La auditoría es otra pieza relevante. CaddyManager registra acciones de usuarios y del sistema, algo útil para seguridad, cumplimiento interno y trazabilidad. En cualquier herramienta que toca configuración de edge o servidores web, saber quién cambió qué y cuándo no es un detalle menor.
SQLite por defecto y MongoDB para despliegues más grandes
Uno de los aciertos del proyecto es ofrecer dos opciones de base de datos. SQLite viene como opción predeterminada, sin configuración adicional, pensada para pruebas, desarrollo y despliegues pequeños o medianos. Todo queda en un único archivo, lo que simplifica la puesta en marcha y evita depender de un servicio externo desde el primer minuto.
Para entornos más grandes o con más carga, CaddyManager también permite usar MongoDB. Esta opción requiere más configuración, pero puede encajar mejor en despliegues con varios usuarios, más tráfico administrativo o necesidades de escalado. Cambiar entre motores se hace mediante la variable de entorno DB_ENGINE, con opciones sqlite o mongodb.
La instalación propuesta mediante Docker Compose separa backend y frontend. El backend no queda expuesto directamente, ya que el frontend actúa como proxy para las rutas /api/*. También se incluye un perfil opcional para levantar MongoDB, aunque SQLite queda como camino más sencillo para empezar.
Este enfoque facilita probar la herramienta con pocos pasos, pero el propio ejemplo de configuración deja claro algo básico para producción: hay que cambiar secretos, contraseñas y valores por defecto. El usuario inicial del sistema se crea como admin con contraseña caddyrocks, una credencial que debe modificarse inmediatamente tras el primer acceso.
Métricas, Prometheus y API documentada
CaddyManager no se queda en una interfaz visual. El proyecto expone métricas de ejecución y aplicación en dos formatos: un endpoint Prometheus en /api/v1/metrics/prometheus y otro JSON agregado en /api/v1/metrics. Esto permite integrarlo con sistemas de monitorización o construir paneles propios si el equipo ya trabaja con Prometheus.
También incluye documentación Swagger para explorar y probar las APIs del backend directamente desde la interfaz. Para administradores y equipos DevOps, este punto es relevante: una herramienta de gestión visual gana valor cuando también permite automatización, integración y acceso programático controlado.
El stack técnico está orientado a una aplicación web moderna: Vue 3, Vite, Pinia y Vue Router en el frontend; Node.js y Express en el backend; SQLite o MongoDB como base de datos; y una integración RESTful para administrar servidores Caddy2. También se mencionan scripts de desarrollo para levantar servidores Caddy de prueba, tanto personalizados como instancias vanilla, útiles para validar la herramienta sin tocar sistemas reales.
Una herramienta prometedora, pero todavía joven
CaddyManager aparece en un momento en el que cada vez más equipos buscan interfaces sencillas para herramientas potentes. Caddy ya simplifica mucho la publicación web frente a configuraciones más pesadas, pero no todos los equipos quieren administrar cada cambio editando archivos o entrando por consola. Una capa web puede ayudar a ordenar tareas, reducir errores y acercar la operación a perfiles menos acostumbrados a trabajar directamente con Caddyfiles.
El riesgo, como siempre en herramientas de gestión de infraestructura, está en la madurez. Si una interfaz administra servidores web, configuraciones, usuarios, API keys y auditoría, debe ser estable, segura y predecible. Un fallo en una herramienta de este tipo puede afectar a la disponibilidad de servicios o introducir configuraciones no deseadas. Por eso la advertencia del proyecto sobre su estado temprano no debe tomarse como una formalidad.
Para laboratorios, pruebas internas, pequeños entornos o equipos que quieran experimentar con gestión visual de Caddy2, CaddyManager puede ser un proyecto interesante. Para producción, la recomendación razonable es probar primero en un entorno aislado, revisar los permisos, cambiar credenciales por defecto, proteger bien el acceso, validar backups de configuración y entender cómo se comporta ante errores.
Su propuesta, en cualquier caso, apunta a una necesidad real: administrar Caddy2 con más visibilidad, más control de usuarios y mejor trazabilidad. Si el proyecto madura, puede convertirse en una pieza útil para quienes quieren mantener la simplicidad de Caddy sin renunciar a una interfaz de gestión más cómoda.
Preguntas frecuentes
¿Qué es CaddyManager?
CaddyManager es una interfaz web open source para gestionar servidores Caddy2 desde un panel moderno, con soporte para múltiples servidores, edición de Caddyfiles, usuarios, API keys, métricas y auditoría.
¿Sustituye a Caddy?
No. CaddyManager actúa como capa de administración sobre servidores Caddy2. Caddy sigue siendo el servidor que ejecuta las configuraciones.
¿Qué base de datos utiliza?
Por defecto usa SQLite, sin configuración adicional. También permite usar MongoDB para despliegues más grandes o con más necesidades de escalado.
¿Está listo para producción?
El propio proyecto indica que está en desarrollo temprano y recomienda hacer copias de seguridad antes de probarlo. Lo prudente es validarlo primero en entornos controlados.
¿Cómo se instala?
El proyecto propone despliegue mediante Docker Compose, con backend, frontend y opción de MongoDB. SQLite funciona por defecto con datos persistentes en volumen Docker.
