How we built an automation platform for 600+ managed servers
And why we replaced n8n with Laravel along the way
Cuando empezamos a construir nuestra plataforma interna de automatización, pensábamos que teníamos el stack correcto. Teníamos n8n para la orquestación de flujos de trabajo, Semaphore UI para ejecutar playbooks de Ansible y una visión de cómo automatizar por completo las operaciones de hosting. Unos meses después, estaba mirando lo que solo puede describirse como una telaraña, y supe que teníamos que empezar de nuevo.
El problema que intentábamos resolver
Soy el CTO de Savvii, una empresa de hosting gestionado con sede en los Países Bajos. Nos especializamos en sitios web basados en PHP — comercio electrónico, WordPress y cargas de trabajo similares — y atendemos a tres verticales de clientes: clientes más pequeños, revendedores y agencias. Cada uno tiene necesidades diferentes, una escala diferente y expectativas diferentes.
La vertical de agencias era donde más sentíamos la presión. Las agencias son clientes sofisticados, pero sus equipos internos suelen ser una mezcla de personas técnicas y no técnicas. Necesitan una interfaz gráfica. No pueden vivir en la línea de comandos. Y cuanto más agencias incorporábamos, más obvio se volvía: necesitábamos un panel de control adecuado respaldado por automatización real.
Ansible Tower y herramientas similares estaban en nuestro radar, pero eran o demasiado complejas de configurar, tenían documentación inconsistente, o venían con preocupaciones de rendimiento y soberanía. Queríamos algo que pudiéramos autoalojar, actualizar sin dramas, y entregar a nuestro equipo de soporte sin una semana de capacitación.
Evaluando las opciones
Hicimos una comparación completa antes de comprometernos con nada. Dos factores acotaron rápidamente el campo.
Soberanía de datos. Ninguna herramienta que almacenara estado o credenciales en una nube de terceros. El autoalojamiento era innegociable.
Experiencia de usuario para no ingenieros. El equipo de soporte de primera línea son grandes comunicadores, no administradores de sistemas. Lo que eligiéramos tenía que ser navegable sin escalar cada incidente a DevOps. Las herramientas que evaluamos incluían:
| Criterio | Semaphore UI | n8n | AWX / Tower | Rundeck |
|---|---|---|---|---|
| Autoalojado por defecto | Sí — binario único / despliegue familiar | Sí — edición autoalojada | Sí (AWX) / mixto (opciones de nube AAP) | Sí |
| Experiencia de usuario para soporte de primera línea | Gran claridad de tareas e inventario | Bueno para autores; débil para el traspaso a operaciones | Conceptos de RBAC pesados; difícil para soporte | Centrado en trabajos; ergonomía de Ansible más complicada |
| Experiencia de inventario y ejecución de Ansible | Construido en torno a proyectos y plantillas | No es un plano de control de Ansible | Nativo pero con una ruta de actualización compleja | Posible; no centrado en Ansible |
| API para middleware personalizado | APIs consistentes de tareas y proyectos | Extensa; modelo operativo diferente | La superficie de la API de Tower varía según la versión | API de trabajos madura; primitivas diferentes |
| Carga de actualización y operativa | Actualizaciones con poca fricción en la práctica | Depende de la dispersión de flujos de trabajo | A menudo pesada (K8s / dependencias incluidas) | Moderada; huella de la JVM |
Semaphore UI ganó en ambos aspectos. La instalación fue sencilla. Las actualizaciones fueron indoloras. La interfaz era lo suficientemente limpia como para que un no ingeniero pudiera entender lo que estaba pasando. Conectar nuestro inventario de Ansible existente fue casi sin fricciones — el único punto en el que necesitamos ayuda fue conseguir conectar nuestro inventario, y eso se resolvió rápidamente con el soporte. La documentación de Semaphore era sólida, y eso nos dio confianza.
La primera arquitectura: n8n como middleware
La arquitectura inicial usaba n8n como capa de orquestación entre HostBill (facturación), Semaphore UI y el CMDB. Sobre el papel, parecía limpia — de bajo código, visual, sin necesidad de un desarrollador para mantenerla.
Qué salió mal con n8n
La interfaz visual de n8n es estupenda para flujos lineales simples. Pero en cuanto los condicionales, el manejo de errores, las devoluciones de llamada de varios pasos y la gestión de estado entraron en escena — la visión general desapareció. Lo que empezó como un diagrama limpio se convirtió en una placa de circuito surrealista.
Sin almacenamiento de estado seguro
No había forma segura de almacenar el estado intermedio entre pasos en la versión que estábamos usando.
Preocupaciones de seguridad
No había un enmascaramiento fiable de contraseñas en los registros — una preocupación seria cuando las devoluciones de llamada de Ansible incluyen credenciales generadas.
Devoluciones de llamada frágiles
El manejo de devoluciones de llamada entre n8n, Semaphore y el CMDB requería un ida y vuelta excesivo que hacía los flujos frágiles.
La nueva arquitectura: Laravel como middleware
Reemplazamos n8n con una aplicación Laravel. Es un middleware adecuado — no una herramienta sin código, sino algo que nuestro equipo posee y entiende por completo.
Modelo de seguridad
Cada servidor tiene un archivo authorized_keys que restringe lo que la clave SSH de Semaphore puede hacer realmente. Usando la directiva command en authorized_keys, definimos exactamente qué comandos puede ejecutar Semaphore. Tras la configuración inicial, Semaphore también pierde el acceso root — solo puede conectarse a cuentas de usuario.
Esto limita significativamente el radio de impacto si algo llegara a verse comprometido.
Dónde estamos ahora
La vertical de agencias, donde empezamos, ejecuta alrededor de 600 servidores a través de esta arquitectura. La huella total en las tres verticales será finalmente de 3.000 a 4.000 servidores, y estamos desplegando la plataforma de forma progresiva.
El programador de Semaphore es lo siguiente en la lista para las actualizaciones de servidores — actualmente gestionadas con herramientas externas, pero pasando a Ansible con el programador a cargo.
Independencia del soporte
El soporte puede usar Semaphore de forma independiente sin involucrar a DevOps en cada incidente.
Alertas en tiempo real
La integración con Slack da a ingeniería alertas instantáneas cuando fallan los playbooks.
Plantillas limpias
Bajo número de plantillas al pasar variables a través de la API — se evitó la dispersión.
CMDB preciso
El CMDB se mantiene preciso automáticamente — se acabó el mantenimiento manual.
Si empezáramos de nuevo hoy
Lo más importante que haríamos de forma diferente: dedicar más tiempo al diseño de la arquitectura antes de escribir una sola línea de automatización. Empezamos de nuevo más de una vez porque no habíamos pensado con suficiente cuidado en qué flujos escalarían y cuáles manejarían los fallos con elegancia.
La arquitectura primero
Dedica más tiempo al diseño de la arquitectura antes de escribir una sola línea de automatización. Piensa con cuidado en qué flujos escalarán y manejarán los fallos con elegancia.
Evalúa por la experiencia de usuario, no solo por la capacidad
Si tu equipo de soporte no puede usarla a las 2 de la madrugada sin llamar a un ingeniero senior, es la herramienta equivocada.
La soberanía de datos importa
Saber dónde viven tus credenciales y tu estado antes de estar en producción.
Una buena documentación es una señal
Si la documentación de una herramienta es un desastre, la herramienta probablemente también lo sea.
Ready to automate your infrastructure?
Start with OSS, upgrade to Pro when your team grows. Enterprise support and SLA are available — including for hosting providers running thousands of servers.