How we built an automation platform for 600+ managed servers
And why we replaced n8n with Laravel along the way
Quando abbiamo iniziato a costruire la nostra piattaforma di automazione interna, pensavamo di avere lo stack giusto. Avevamo n8n per l'orchestrazione dei workflow, Semaphore UI per l'esecuzione dei playbook Ansible e una visione su come automatizzare completamente le operazioni di hosting. Qualche mese dopo, mi ritrovavo a fissare quello che si può solo descrivere come una ragnatela — e sapevo che dovevamo ricominciare da capo.
Il problema che stavamo cercando di risolvere
Sono il CTO di Savvii, un'azienda di managed hosting con sede nei Paesi Bassi. Siamo specializzati in siti web basati su PHP — e-commerce, WordPress e carichi di lavoro simili — e serviamo tre segmenti di clienti: clienti più piccoli, reseller e agenzie. Ognuno ha esigenze diverse, scala diversa e aspettative diverse.
Il segmento delle agenzie era quello dove sentivamo di più la pressione. Le agenzie sono clienti sofisticati, ma i loro team interni sono spesso un mix di persone tecniche e non tecniche. Hanno bisogno di una GUI. Non possono vivere nella riga di comando. E più agenzie facevamo onboarding, più diventava ovvio: avevamo bisogno di un vero pannello di controllo supportato da un'automazione reale.
Ansible Tower e strumenti simili erano sul nostro radar, ma erano o troppo complessi da configurare, avevano una documentazione incoerente, oppure presentavano problemi di prestazioni e di sovranità. Volevamo qualcosa che potessimo ospitare in autonomia, aggiornare senza drammi e affidare al nostro team di supporto senza una settimana di formazione.
Valutare le opzioni
Abbiamo fatto un confronto completo prima di impegnarci su qualcosa. Due fattori hanno ristretto rapidamente il campo.
Sovranità dei dati. Nessuno strumento che memorizzasse stato o credenziali in un cloud di terze parti. L'hosting in autonomia era irrinunciabile.
UX per i non ingegneri. Il team di supporto di primo livello è fatto di ottimi comunicatori, non di sysadmin. Qualunque cosa scegliessimo doveva essere navigabile senza dover escalare ogni incidente al DevOps. Gli strumenti che abbiamo valutato includevano:
| Criterio | Semaphore UI | n8n | AWX / Tower | Rundeck |
|---|---|---|---|---|
| Self-hosted per impostazione predefinita | Sì — singolo binario / deploy familiare | Sì — edizione self-hosted | Sì (AWX) / misto (opzioni cloud AAP) | Sì |
| UX per il supporto di primo livello | Forte chiarezza di task & inventario | Buono per gli autori; debole per il passaggio alle operazioni | Concetti RBAC pesanti; ripido per il supporto | Centrato sui job; ergonomia Ansible più ripida |
| UX di inventario & esecuzione Ansible | Costruito attorno a progetti & template | Non è un control plane per Ansible | Nativo ma percorso di aggiornamento complesso | Possibile; non Ansible-first |
| API per middleware personalizzato | API coerenti per task & progetti | Estese; modello operativo diverso | La superficie API di Tower varia per versione | API per job matura; primitive diverse |
| Onere di aggiornamento & operativo | Aggiornamenti a basso attrito nella pratica | Dipende dalla proliferazione dei workflow | Spesso pesante (K8s / dipendenze incluse) | Moderato; footprint JVM |
Semaphore UI ha vinto su entrambi i fronti. L'installazione è stata semplice. Gli aggiornamenti erano indolori. L'interfaccia era abbastanza pulita da permettere a un non ingegnere di capire cosa stava succedendo. Collegare il nostro inventario Ansible esistente è stato quasi privo di attriti — l'unico punto in cui abbiamo avuto bisogno di aiuto è stato collegare il nostro inventario, e si è risolto rapidamente con il supporto. La documentazione di Semaphore era solida, e questo ci ha dato fiducia.
La prima architettura: n8n come middleware
L'architettura iniziale usava n8n come livello di orchestrazione tra HostBill (fatturazione), Semaphore UI e il CMDB. Sulla carta sembrava pulita — low-code, visuale, nessuno sviluppatore necessario per mantenerla.
Cosa è andato storto con n8n
L'interfaccia visuale di n8n è ottima per flussi lineari semplici. Ma una volta entrati in gioco condizionali, gestione degli errori, callback multi-step e gestione dello stato — la visione d'insieme è svanita. Quello che era iniziato come un diagramma pulito si è trasformato in un circuito stampato surrealista.
Nessuna archiviazione sicura dello stato
Nessun modo sicuro per memorizzare lo stato intermedio tra i passaggi nella versione che stavamo usando.
Problemi di sicurezza
Nessun mascheramento affidabile delle password nei log — una preoccupazione seria quando le callback di Ansible includono credenziali generate.
Callback fragili
La gestione delle callback tra n8n, Semaphore e il CMDB richiedeva un eccessivo andirivieni che rendeva i flussi fragili.
La nuova architettura: Laravel come middleware
Abbiamo sostituito n8n con un'applicazione Laravel. È vero middleware — non uno strumento no-code, ma qualcosa che il nostro team possiede e comprende completamente.
Modello di sicurezza
Ogni server ha un file authorized_keys che limita ciò che la chiave SSH di Semaphore può effettivamente fare. Usando la direttiva command in authorized_keys, definiamo esattamente quali comandi Semaphore è autorizzato a eseguire. Dopo la configurazione iniziale, Semaphore perde anche l'accesso root — può connettersi solo agli account utente.
Questo limita notevolmente il raggio d'azione se qualcosa dovesse mai essere compromesso.
A che punto siamo ora
Il segmento delle agenzie, da cui siamo partiti, gestisce circa 600 server attraverso questa architettura. Il footprint totale su tutti e tre i segmenti sarà alla fine di 3.000-4.000 server, e stiamo distribuendo la piattaforma in modo progressivo.
Lo scheduler di Semaphore è il prossimo in lista per gli aggiornamenti dei server — attualmente gestiti con strumenti esterni, ma in transizione verso Ansible con lo scheduler a guidarlo.
Indipendenza del supporto
Il supporto può usare Semaphore in autonomia senza coinvolgere il DevOps in ogni incidente.
Avvisi in tempo reale
L'integrazione con Slack dà all'engineering avvisi istantanei quando i playbook falliscono.
Template puliti
Basso numero di template passando le variabili tramite API — evitata la proliferazione.
CMDB accurato
Il CMDB rimane accurato automaticamente — niente più manutenzione manuale.
Se ricominciassimo da capo oggi
La cosa più importante che faremmo diversamente: dedicare più tempo alla progettazione dell'architettura prima di scrivere una singola riga di automazione. Abbiamo ricominciato da capo più di una volta perché non avevamo pensato con sufficiente attenzione a quali flussi sarebbero stati scalabili e quali avrebbero gestito i guasti con eleganza.
L'architettura prima di tutto
Dedica più tempo alla progettazione dell'architettura prima di scrivere una singola riga di automazione. Pensa con attenzione a quali flussi saranno scalabili e gestiranno i guasti con eleganza.
Valuta sull'UX, non solo sulle funzionalità
Se il tuo team di supporto non riesce a usarlo alle 2 di notte senza chiamare un ingegnere senior, è lo strumento sbagliato.
La sovranità dei dati conta
Sappi dove risiedono le tue credenziali e il tuo stato prima di essere in produzione.
Una buona documentazione è un segnale
Se la documentazione di uno strumento è un disastro, probabilmente lo è anche lo strumento.
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.