And why we replaced n8n with Laravel along the way
Da vi begyndte at bygge vores interne automatiseringsplatform, troede vi, at vi havde det rette teknologiske stack. Vi havde n8n til workflow-orkestrering, Semaphore UI til afvikling af Ansible-playbooks og en vision for, hvordan vi kunne automatisere hosting-driften fuldstændigt. Nogle måneder inde i projektet stirrede jeg på noget, der kun kan beskrives som et edderkoppespind — og jeg vidste, at vi var nødt til at starte forfra.
Jeg er CTO hos Savvii, en administreret hostingvirksomhed baseret i Holland. Vi er specialiseret i PHP-baserede hjemmesider — e-handel, WordPress og lignende arbejdsbyrder — og betjener tre kundesegmenter: mindre kunder, forhandlere (resellere) og bureauer. Hver har forskellige behov, forskellig skala og forskellige forventninger.
Det var bureau-segmentet, hvor vi følte presset mest. Bureauer er sofistikerede kunder, men deres interne teams er ofte en blanding af tekniske og ikke-tekniske folk. De har brug for en GUI. De kan ikke arbejde i kommandolinjen. Og jo flere bureauer vi tog ind, desto mere indlysende blev det: vi havde brug for et ordentligt kontrolpanel understøttet af ægte automatisering.
Ansible Tower og lignende værktøjer var i vores søgelys, men de var enten for komplekse at sætte op, havde inkonsistent dokumentation eller medførte bekymringer om ydeevne og datasuverænitet. Vi ønskede en løsning, vi selv kunne hoste, opgradere uden drama og overlade til vores supportteam uden en uges forudgående træning.
Vi foretog en grundig sammenligning, inden vi lagde os fast på noget. To faktorer indsnævrede hurtigt feltet.
Datasuverænitet. Intet værktøj, der gemte tilstand eller legitimationsoplysninger i en tredjepartssky, kom i betragtning. Selvhosting var ikke til forhandling.
UX for ikke-ingeniører. Vores førstelinjesupport er dygtige formidlere, ikke systemadministratorer. Uanset hvad vi valgte, skulle det kunne betjenes uden at eskalere enhver hændelse til DevOps. De værktøjer, vi vurderede, omfattede:
| Kriterium | Semaphore UI | n8n | AWX / Tower | Rundeck |
|---|---|---|---|---|
| Selvhostet som standard | Ja — enkelt binær fil / velkendt udrulning | Ja — selvhostet udgave | Ja (AWX) / blandet (AAP sky-muligheder) | Ja |
| UX for førstelinjesupport | Fremragende klarhed omkring opgaver og fortegnelser | Godt for forfattere; svagt til driftsoverdragelse | Tunge RBAC-koncepter; stejl læringskurve for support | Job-centreret; mere besværlig Ansible-ergonomi |
| Ansible-fortegnelse & eksekverings-UX | Bygget op omkring projekter og skabeloner | Ikke et kontrolplan til Ansible | Indbygget, men kompleks opgraderingsvej | Muligt; ikke primært rettet mod Ansible |
| API til tilpasset middleware | Ensartede opgave- og projekt-API'er | Omfattende; helt anden driftsmodel | Tower API-overflade varierer efter version | Modent job-API; andre basiselementer |
| Opgraderings- og driftsbyrde | Problemfrie opgraderinger i praksis | Afhænger af workflow-vækst | Ofte tung (K8s / samlede afhængigheder) | Moderat; JVM-ressourceforbrug |
Semaphore UI vandt på begge punkter. Installationen var enkel. Opgraderinger var smertefrie. Brugerfladen var så overskuelig, at en person uden ingeniørbaggrund kunne forstå, hvad der foregik. Tilslutningen af vores eksisterende Ansible-fortegnelse forløb næsten uden gnidninger — det eneste punkt, hvor vi havde brug for hjælp, var at få vores fortegnelse forbundet, og det blev hurtigt løst via support. Semaphores dokumentation var solid, og det gav os tryghed.
Den oprindelige arkitektur anvendte n8n som orkestreringslag mellem HostBill (fakturering), Semaphore UI og CMDB'en. På papiret så det elegant ud — visuelt, low-code, uden behov for en udvikler til at vedligeholde det.
n8n's visuelle brugerflade er glimrende til enkle, lineære flows. Men da betingelser, fejlhåndtering, flertrins-callbacks og tilstandsstyring kom ind i billedet — forsvandt overblikket. Hvad der startede som et overskueligt diagram, udviklede sig til et surrealistisk kredsløb.
Ingen sikker tilstandslagring
Ingen sikker måde at gemme mellemliggende tilstand mellem trin i den version, vi brugte.
Sikkerhedsmæssige bekymringer
Manglende pålidelig sløring af adgangskoder i logfiler — en alvorlig bekymring, når Ansible-callbacks indeholder genererede legitimationsoplysninger.
Skrøbelige callbacks
Håndteringen af callbacks mellem n8n, Semaphore og CMDB krævede uforholdsmæssigt megen kommunikation frem og tilbage, hvilket gjorde workflows skrøbelige.
Vi erstattede n8n med en Laravel-applikation. Det er en rigtig middleware — ikke et no-code værktøj, men noget vores team fuldt ud ejer og forstår.
Sikkerhedsmodel
Hver server har en authorized_keys-fil, der begrænser, hvad Semaphore SSH-nøglen rent faktisk kan gøre. Ved hjælp af command-direktivet i authorized_keys definerer vi præcist, hvilke kommandoer Semaphore har lov til at køre. Efter den indledende opsætning mister Semaphore også root-adgang — den kan kun forbinde til brugerkonti.
Dette begrænser skadesomfanget (blast radius) markant, hvis noget nogensinde skulle blive kompromitteret.
Bureau-segmentet, hvor vi startede, kører omkring 600 servere via denne arkitektur. Det samlede omfang på tværs af alle tre segmenter vil i sidste ende være 3.000 til 4.000 servere, og vi udruller platformen løbende.
Semaphores scheduler er næste skridt til serveropdateringer — p.t. håndteres det med eksterne værktøjer, men flyttes til Ansible drevet af scheduleren.
Uafhængig support
Supportteamet kan bruge Semaphore selvstændigt uden at inddrage DevOps ved hver hændelse.
Realtidsalarmer
Slack-integration giver udviklingsteamet øjeblikkelige alarmer, når playbooks fejler.
Rene skabeloner
Lavt antal skabeloner ved at overføre variabler via API — undgik unødig vækst.
Nøjagtig CMDB
CMDB'en holdes automatisk ajour — slut med manuel vedligeholdelse.
Den største ting, vi ville gøre anderledes: bruge mere tid på arkitekturdesign, før der skrives en eneste linje automatisering. Vi startede forfra mere end én gang, fordi vi ikke havde gennemtænkt nøje nok, hvilke flows der ville skalere, og hvilke der ville håndtere fejl hensigtsmæssigt.
Arkitektur først
Brug mere tid på arkitekturdesign, før der skrives en eneste linje automatisering. Tænk nøje over, hvilke flows der vil skalere og håndtere fejl hensigtsmæssigt.
Vurder på UX, ikke kun funktioner
Hvis dit supportteam ikke kan bruge det kl. 02 om natten uden at tilkalde en senioringeniør, er det det forkerte værktøj.
Datasuverænitet har betydning
Hav styr på, hvor dine legitimationsoplysninger og tilstandsdata befinder sig, før du går i produktion.
God dokumentation er et signal
Hvis et værktøjs dokumentation sejler, gælder det sandsynligvis også for selve værktøjet.
Start with OSS, upgrade to Pro when your team grows. Enterprise support and SLA are available — including for hosting providers running thousands of servers.
