How we built an automation platform for 600+ managed servers
And why we replaced n8n with Laravel along the way
Lorsque nous avons commencé à construire notre plateforme d'automatisation interne, nous pensions disposer de la bonne stack. Nous avions n8n pour l'orchestration des workflows, Semaphore UI pour exécuter les playbooks Ansible, et une vision de la manière d'automatiser entièrement les opérations d'hébergement. Quelques mois plus tard, je contemplais ce qu'on ne peut décrire que comme une toile d'araignée — et je savais que nous devions tout recommencer.
Le problème que nous tentions de résoudre
Je suis le CTO de Savvii, une société d'hébergement infogéré basée aux Pays-Bas. Nous sommes spécialisés dans les sites web basés sur PHP — e-commerce, WordPress et charges de travail similaires — et nous servons trois segments de clientèle : les petits clients, les revendeurs et les agences. Chacun a des besoins différents, une échelle différente et des attentes différentes.
C'est sur le segment des agences que nous ressentions le plus la pression. Les agences sont des clients exigeants, mais leurs équipes internes sont souvent un mélange de personnes techniques et non techniques. Elles ont besoin d'une interface graphique. Elles ne peuvent pas vivre dans la ligne de commande. Et plus nous intégrions d'agences, plus cela devenait évident : nous avions besoin d'un véritable panneau de contrôle adossé à une automatisation réelle.
Ansible Tower et des outils similaires étaient sur notre radar, mais ils étaient soit trop complexes à mettre en place, soit dotés d'une documentation incohérente, soit assortis de préoccupations de performance et de souveraineté. Nous voulions quelque chose que nous pouvions auto-héberger, mettre à niveau sans drame, et confier à notre équipe support sans une semaine de formation.
Évaluer les options
Nous avons réalisé une comparaison complète avant de nous engager. Deux facteurs ont rapidement restreint le champ.
Souveraineté des données. Aucun outil stockant l'état ou les identifiants dans un cloud tiers. L'auto-hébergement était non négociable.
UX pour les non-ingénieurs. L'équipe support de première ligne est composée de bons communicants, pas d'administrateurs système. Quel que soit notre choix, il devait être navigable sans escalader chaque incident vers le DevOps. Les outils que nous avons évalués comprenaient :
| Critère | Semaphore UI | n8n | AWX / Tower | Rundeck |
|---|---|---|---|---|
| Auto-hébergé par défaut | Oui — binaire unique / déploiement familier | Oui — édition auto-hébergée | Oui (AWX) / mixte (options cloud AAP) | Oui |
| UX pour le support de première ligne | Grande clarté des tâches & de l'inventaire | Bon pour les auteurs ; faible pour le transfert aux ops | Concepts RBAC lourds ; ardu pour le support | Centré sur les jobs ; ergonomie Ansible plus ardue |
| UX d'inventaire & d'exécution Ansible | Conçu autour des projets & des templates | N'est pas un plan de contrôle Ansible | Natif mais chemin de mise à niveau complexe | Possible ; pas orienté Ansible en premier |
| API pour middleware personnalisé | API de tâches & de projets cohérentes | Étendue ; modèle opérationnel différent | La surface de l'API Tower varie selon la version | API de jobs mature ; primitives différentes |
| Charge de mise à niveau & opérationnelle | Mises à niveau peu contraignantes en pratique | Dépend de la prolifération des workflows | Souvent lourde (K8s / dépendances groupées) | Modérée ; empreinte JVM |
Semaphore UI a gagné sur les deux tableaux. L'installation était simple. Les mises à niveau étaient indolores. L'interface était suffisamment claire pour qu'une personne non ingénieure puisse comprendre ce qui se passait. Le branchement de notre inventaire Ansible existant a été presque sans friction — le seul point où nous avons eu besoin d'aide a été la connexion de notre inventaire, et cela a été résolu rapidement avec le support. La documentation de Semaphore était solide, et cela nous a donné confiance.
La première architecture : n8n comme middleware
L'architecture initiale utilisait n8n comme couche d'orchestration entre HostBill (facturation), Semaphore UI et la CMDB. Sur le papier, cela semblait propre — low-code, visuel, aucun développeur requis pour la maintenir.
Ce qui n'a pas fonctionné avec n8n
L'interface visuelle de n8n est excellente pour les flux linéaires simples. Mais dès que les conditions, la gestion des erreurs, les callbacks multi-étapes et la gestion de l'état sont entrés en jeu — la vue d'ensemble a disparu. Ce qui avait commencé comme un diagramme propre s'est transformé en un circuit imprimé surréaliste.
Aucun stockage d'état sûr
Aucun moyen sûr de stocker l'état intermédiaire entre les étapes dans la version que nous utilisions.
Préoccupations de sécurité
Aucun masquage fiable des mots de passe dans les journaux — une préoccupation sérieuse lorsque les callbacks Ansible incluent des identifiants générés.
Callbacks fragiles
La gestion des callbacks entre n8n, Semaphore et la CMDB nécessitait des allers-retours excessifs qui rendaient les flux fragiles.
La nouvelle architecture : Laravel comme middleware
Nous avons remplacé n8n par une application Laravel. C'est un véritable middleware — pas un outil no-code, mais quelque chose que notre équipe possède et comprend pleinement.
Modèle de sécurité
Chaque serveur possède un fichier authorized_keys qui restreint ce que la clé SSH de Semaphore peut réellement faire. À l'aide de la directive command dans authorized_keys, nous définissons exactement quelles commandes Semaphore est autorisé à exécuter. Après la configuration initiale, Semaphore perd également l'accès root — il ne peut se connecter qu'à des comptes utilisateurs.
Cela limite considérablement le rayon d'impact en cas de compromission.
Où nous en sommes maintenant
Le segment des agences, par lequel nous avons commencé, fait fonctionner environ 600 serveurs à travers cette architecture. L'empreinte totale sur les trois segments atteindra à terme 3 000 à 4 000 serveurs, et nous déployons la plateforme progressivement.
Le planificateur de Semaphore est la prochaine étape pour les mises à jour des serveurs — actuellement gérées avec un outillage externe, mais en cours de migration vers Ansible piloté par le planificateur.
Indépendance du support
Le support peut utiliser Semaphore de manière indépendante sans solliciter le DevOps à chaque incident.
Alertes en temps réel
L'intégration Slack fournit à l'ingénierie des alertes instantanées en cas d'échec des playbooks.
Templates épurés
Faible nombre de templates en passant les variables via l'API — prolifération évitée.
CMDB précise
La CMDB reste précise automatiquement — plus de maintenance manuelle.
Si nous recommencions aujourd'hui
La seule chose la plus importante que nous ferions différemment : consacrer plus de temps à la conception de l'architecture avant d'écrire la moindre ligne d'automatisation. Nous avons recommencé plus d'une fois parce que nous n'avions pas suffisamment réfléchi à quels flux passeraient à l'échelle, et lesquels géreraient les défaillances avec élégance.
L'architecture d'abord
Consacrez plus de temps à la conception de l'architecture avant d'écrire la moindre ligne d'automatisation. Réfléchissez attentivement à quels flux passeront à l'échelle et géreront les défaillances avec élégance.
Évaluez sur l'UX, pas seulement sur les capacités
Si votre équipe support ne peut pas l'utiliser à 2h du matin sans appeler un ingénieur senior, c'est le mauvais outil.
La souveraineté des données compte
Sachez où résident vos identifiants et votre état avant d'être en production.
Une bonne documentation est un signal
Si la documentation d'un outil est en désordre, l'outil l'est probablement aussi.
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.