How we built an automation platform for 600+ managed servers
And why we replaced n8n with Laravel along the way
Quando começámos a construir a nossa plataforma interna de automação, pensávamos ter a stack certa. Tínhamos o n8n para orquestração de workflows, o Semaphore UI para executar playbooks Ansible e uma visão de como automatizar totalmente as operações de hosting. Alguns meses depois, eu estava a olhar para algo que só pode ser descrito como uma teia de aranha — e sabia que tínhamos de começar de novo.
O problema que tentávamos resolver
Sou o CTO da Savvii, uma empresa de managed hosting sediada nos Países Baixos. Especializamo-nos em websites baseados em PHP — e-commerce, WordPress e cargas de trabalho semelhantes — e servimos três verticais de clientes: clientes mais pequenos, revendedores e agências. Cada uma tem necessidades diferentes, escalas diferentes e expectativas diferentes.
A vertical das agências era onde sentíamos mais a pressão. As agências são clientes sofisticados, mas as suas equipas internas são frequentemente uma mistura de pessoas técnicas e não técnicas. Precisam de uma GUI. Não conseguem viver na linha de comandos. E quantas mais agências integrávamos, mais óbvio se tornava: precisávamos de um painel de controlo adequado, suportado por automação real.
O Ansible Tower e ferramentas semelhantes estavam no nosso radar, mas eram demasiado complexos de configurar, tinham documentação inconsistente ou traziam preocupações de desempenho e de soberania. Queríamos algo que pudéssemos alojar nós próprios, atualizar sem dramas e entregar à nossa equipa de suporte sem uma semana de formação.
Avaliar as opções
Fizemos uma comparação completa antes de nos comprometermos com qualquer coisa. Dois fatores reduziram rapidamente o campo de opções.
Soberania dos dados. Nenhuma ferramenta que armazenasse estado ou credenciais numa cloud de terceiros. O self-hosting era inegociável.
UX para não engenheiros. A equipa de suporte de primeira linha são bons comunicadores, não administradores de sistemas. O que quer que escolhêssemos tinha de ser navegável sem escalar cada incidente para o DevOps. As ferramentas que avaliámos incluíam:
| Critério | Semaphore UI | n8n | AWX / Tower | Rundeck |
|---|---|---|---|---|
| Self-hosted por padrão | Sim — binário único / deploy familiar | Sim — edição self-hosted | Sim (AWX) / misto (opções de cloud AAP) | Sim |
| UX para suporte de primeira linha | Forte clareza de tarefas & inventário | Bom para autores; fraco para entrega às ops | Conceitos pesados de RBAC; íngreme para o suporte | Centrado em jobs; ergonomia de Ansible mais íngreme |
| UX de inventário & execução Ansible | Construído em torno de projetos & templates | Não é um control plane de Ansible | Nativo mas caminho de atualização complexo | Possível; não é Ansible-first |
| API para middleware personalizado | APIs consistentes de tarefas & projetos | Extensa; modelo operacional diferente | A superfície da API do Tower varia consoante a versão | API de jobs madura; primitivas diferentes |
| Esforço de atualização & operacional | Atualizações de baixo atrito na prática | Depende da dispersão de workflows | Frequentemente pesado (K8s / dependências agrupadas) | Moderado; pegada de JVM |
O Semaphore UI venceu em ambos os pontos. A instalação foi direta. As atualizações foram indolores. A interface era suficientemente limpa para que um não engenheiro pudesse compreender o que estava a acontecer. Ligar o nosso inventário Ansible existente foi quase sem atrito — o único ponto em que precisámos de ajuda foi ligar o nosso inventário, e isso foi resolvido rapidamente com o suporte. A documentação do Semaphore era sólida, e isso deu-nos confiança.
A primeira arquitetura: n8n como middleware
A arquitetura inicial usava o n8n como camada de orquestração entre o HostBill (faturação), o Semaphore UI e o CMDB. No papel, parecia limpa — low-code, visual, sem necessidade de um programador para a manter.
O que correu mal com o n8n
A interface visual do n8n é ótima para fluxos lineares simples. Mas assim que condicionais, tratamento de erros, callbacks de múltiplos passos e gestão de estado entraram em cena — a visão geral desapareceu. O que começou como um diagrama limpo transformou-se numa placa de circuito surrealista.
Sem armazenamento de estado seguro
Não havia forma segura de armazenar estado intermédio entre passos na versão que usávamos.
Preocupações de segurança
Sem mascaramento fiável de palavras-passe nos logs — uma preocupação séria quando os callbacks do Ansible incluem credenciais geradas.
Callbacks frágeis
O tratamento de callbacks entre o n8n, o Semaphore e o CMDB exigia idas e vindas excessivas que tornavam os fluxos frágeis.
A nova arquitetura: Laravel como middleware
Substituímos o n8n por uma aplicação Laravel. É middleware adequado — não uma ferramenta no-code, mas algo que a nossa equipa possui e compreende totalmente.
Modelo de segurança
Cada servidor tem um ficheiro authorized_keys que restringe o que a chave SSH do Semaphore pode realmente fazer. Usando a diretiva command no authorized_keys, definimos exatamente quais os comandos que o Semaphore está autorizado a executar. Após a configuração inicial, o Semaphore também perde o acesso root — só pode ligar-se a contas de utilizador.
Isto limita significativamente o raio de impacto se algo alguma vez fosse comprometido.
Onde estamos agora
A vertical das agências, onde começámos, executa cerca de 600 servidores através desta arquitetura. A pegada total nas três verticais será eventualmente de 3.000 a 4.000 servidores, e estamos a lançar a plataforma de forma progressiva.
O scheduler do Semaphore é o próximo passo para as atualizações de servidores — atualmente tratadas com ferramentas externas, mas a migrar para Ansible com o scheduler a conduzi-las.
Independência do suporte
O suporte pode usar o Semaphore de forma independente sem envolver o DevOps em cada incidente.
Alertas em tempo real
A integração com o Slack dá à engenharia alertas instantâneos quando os playbooks falham.
Templates limpos
Baixo número de templates ao passar variáveis via API — evitámos a dispersão.
CMDB rigoroso
O CMDB mantém-se rigoroso automaticamente — sem mais manutenção manual.
Se estivéssemos a recomeçar hoje
A única coisa mais importante que faríamos de forma diferente: dedicar mais tempo ao desenho da arquitetura antes de escrever uma única linha de automação. Recomeçámos mais do que uma vez porque não tínhamos pensado com cuidado suficiente sobre quais os fluxos que escalariam e quais lidariam com falhas de forma graciosa.
A arquitetura primeiro
Dedique mais tempo ao desenho da arquitetura antes de escrever uma única linha de automação. Pense com cuidado sobre quais os fluxos que escalarão e lidarão com falhas de forma graciosa.
Avalie pela UX, não apenas pela capacidade
Se a sua equipa de suporte não a conseguir usar às 2 da manhã sem chamar um engenheiro sénior, é a ferramenta errada.
A soberania dos dados importa
Saiba onde residem as suas credenciais e o seu estado antes de estar em produção.
Boa documentação é um sinal
Se a documentação de uma ferramenta é uma confusão, a ferramenta provavelmente também é.
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.