Behöver ert företag hjälp med att implementera AI? Kontakta oss och få prisoffert här →
AI Skolan ›
januari 22, 2026

WHMCS till Docker: automatiska tjänstedeployeringar

Rickard Andersson Partner, Nodenordic.se

Att provisionera en ”enkel” hostad tjänst i WHMCS borde inte bli en Slack-tråd, en manuell SSH-session och ett uppföljningsärende för att något driftade över natten. Men det blir det. Och det värsta är hur normalt det hinner kännas.

Den här WHMCS Docker-automationen träffar först hostingens driftteam, och spiller sedan över i supportkön och account managers inkorgar. Oavsett om du driver ett litet hostingbolag eller är en byrå som underhåller kundtjänster på en Docker-host blir resultatet detsamma: färre pingpong-ärenden och mer konsekventa driftsättningar.

Det här arbetsflödet gör WHMCS-modulåtgärder till kontrollerade Docker-kommandon över SSH, med ett strukturerat API-svar tillbaka till WHMCS. Du får se vad det automatiserar, vad du behöver och hur du anpassar det till din miljö.

Så fungerar automationen

Hela n8n-flödet, från trigger till slutlig output:

n8n Workflow Template: WHMCS till Docker: automatiska tjänstedeployeringar

Problemet: WHMCS-åtgärder driftsätter inte tjänster av sig själva

WHMCS är riktigt bra på fakturering, livscykelhändelser och att hålla kunddata samlat. Men när en kund klickar på ”Beställ” och förväntar sig en fungerande tjänst skapar inte WHMCS i sig containers, kopplar lagring, applicerar ACL:er eller bekräftar att tjänsten faktiskt går att nå. Så någon får göra det manuellt. Den ”någon” blir också indragen i logguttag, omstarter, paketändringar och lösenordsåterställningar. Några minuter per uppgift låter ofarligt tills det är 20 ärenden om dagen och vartenda ett kräver SSH.

Det eskalerar snabbt. Här är var det fallerar i verkliga team.

  • Provisionering kräver samma uppsättning SSH-kommandon varje gång, och det är lätt att missa ett när det går fort.
  • Support ber om loggar och containerstatistik, så drift måste kontextväxla bara för att kopiera output in i ett svar.
  • Tjänsteändringar (återaktivera, pausa, avsluta) görs inkonsekvent när flera personer hanterar ärenden.
  • Drift smyger sig in eftersom den ”riktiga konfigurationen” ligger i någons terminalhistorik, inte i ett granskningsbart arbetsflöde.

Lösningen: WHMCS triggar n8n, n8n kör Docker över SSH

Det här n8n-arbetsflödet fungerar som en liten API-backend för din WHMCS Docker-modul. WHMCS anropar en säkrad webhook med ett kommando (provisionera, pausa, hämta loggar, starta/stoppa, koppla lagring med mera). n8n kontrollerar att begäran är avsedd för din server, laddar dina miljöparametrar och routar kommandot till rätt åtgärd. Därefter ansluter den till din Docker-host via SSH och kör det fördefinierade scriptet för operationen. Till sist formaterar den output (ofta JSON) och returnerar ett tydligt svar till WHMCS, så att modulen kan visa status lyckad/misslyckad utan gissningar.

Flödet startar vid webhook-endpointen (”Incoming API Hook”). Därifrån validerar n8n domänen, väljer rätt router (tjänst-, container- eller appkommandon) och kör motsvarande SSH-script på Docker-servern. WHMCS får ett konsekvent svar varje gång, så processen blir repeterbar i stället för att vara tribal knowledge.

Det du får: automation vs. resultat

Exempel: så här ser det ut

Säg att du hanterar 15 WHMCS-tjänstehändelser i veckan som vanligtvis triggar manuellt arbete: provisionering, pausa/återaktivera, paketjusteringar och ”hämta loggar”-förfrågningar. Om varje tar cirka 15 minuter SSH-tid (anslut, kör kommandon, verifiera, klistra in resultat) blir det nästan 4 timmar i veckan. Med det här arbetsflödet skickar WHMCS kommandot direkt och n8n gör SSH-jobbet i bakgrunden, så du främst granskar utfallet. I praktiken går du från ”öppna terminal” till ”kolla svar” på ett par minuter per händelse.

Det här behöver du

  • n8n-instans (testa n8n Cloud gratis)
  • Alternativ för egen hosting om du föredrar det (Hostinger fungerar bra)
  • WHMCS för att trigga åtgärder i tjänstens livscykel.
  • Docker-hostserver för att köra containers och Compose-driftsättningar.
  • SSH-uppgifter (skapa på din Docker-serveranvändare).
  • Webhook Basic Auth (skapa i n8n-credentials).

Kunskapsnivå: Medel. Du är bekväm med att sätta WHMCS-modulendpoints, skapa SSH-nycklar/uppgifter och redigera några miljöparametrar.

Vill du inte sätta upp detta själv? Prata med en automationsexpert (gratis 15-minuters konsultation).

Så fungerar det

WHMCS anropar webhooken. En modulåtgärd (som provisionering, pausning eller hämta loggar) anropar n8n:s webhook-endpoint, skyddad med Basic Auth så att slumpmässiga förfrågningar inte släpps in.

n8n validerar begärans kontext. Arbetsflödet laddar dina konfigurerade parametrar och kontrollerar att domänen matchar det du förväntar dig (så att en server inte råkar agera på en annan).

Rätt kommandoväg väljs. Med kommandoroutrar skickar arbetsflödet förfrågan till rätt gren: tjänstens livscykelkommandon, containeroperationer (start/stop, koppla/ta bort lagring, ACL-uppdateringar) eller appnivåoperationer som lösenordsåterställningar och versionsuppslag.

SSH körs och svaret normaliseras. n8n kör motsvarande Bash-script på Docker-hosten och formaterar sedan svaret till en förutsägbar payload som WHMCS kan visa och logga.

Du kan enkelt ändra Compose-mallen och Nginx-konfigurationen så att den matchar din standardstack utifrån dina behov. Se hela implementationsguiden nedan för anpassningsalternativ.

Steg-för-steg-guide för implementering

Steg 1: Konfigurera webhook-triggern

Konfigurera den inkommande API-ingångspunkten som driver alla kommandon för containerorkestrering.

  1. Lägg till och konfigurera Incoming API Hook med Path satt till docker-immich.
  2. Ställ in Authentication till basicAuth och aktivera Multiple Methods satt till true.
  3. Ställ in Response Mode till responseNode så att svar hanteras av Webhook Reply.
  4. Inloggningsuppgifter krävs: Anslut era httpBasicAuth-inloggningsuppgifter i Incoming API Hook.

Tips: Webhooken förväntar sig JSON i body (till exempel command, domain, username, password, disk, ram, cpu).

Steg 2: Definiera standardvärden för miljön och validering av domän

Ställ in standardvägar och validera den inkommande domänen innan några kommandon routas.

  1. I Config Parameters ställer ni in standardvärdena:
    server_domain till d01-test.uuq.pl, clients_dir till /opt/docker/clients, mount_dir till /mnt, screen_left till {{ och screen_right till }}.
  2. Konfigurera Domain Match Check för att jämföra {{ $json.server_domain }} med {{ $('Incoming API Hook').item.json.body.server_domain }}.
  3. Koppla false-grenen från Domain Match Check till Respond Invalid Domain med Respond With satt till json och Response Code till 422.

⚠️ Vanlig fallgrop: Om Config Parameters server_domain inte matchar anropets server_domain kommer workflowet att avbrytas tidigt och returnera Invalid server domain.

Steg 3: Konfigurera parallell routing från Domain Match Check

Efter validering routar workflowet förfrågningar till flera kommandogrenar samtidigt.

  1. Bekräfta att huvudflödet från Config Parameters går vidare till Domain Match Check.
  2. Domain Match Check skickar utdata parallellt till Container Info Router, Container Command Router, App Command Router och Deploy Command Gate.
  3. I Container Info Router säkerställer ni att reglerna mappar till container_information_inspect, container_information_stats, container_log och dependent_containers_information_stats från {{ $('Incoming API Hook').item.json.body.command }}.
  4. I Container Command Router säkerställer ni att utdata mappar till container_start, container_stop, container_mount_disk, container_unmount_disk, container_get_acl, container_set_acl och container_get_net.
  5. I App Command Router verifierar ni utdata för app_version, app_users och change_password.
  6. I Deploy Command Gate ställer ni in villkor för create, change_package och unsuspend med {{ $('Incoming API Hook').item.json.body.command }}.

Tips: Använd tydliga kommandovärden i era API-anrop så att rätt switch-gren aktiveras, särskilt när flera grenar är tillgängliga parallellt.

Steg 4: Bygg driftsättningsmallar och tjänsteåtgärder

Förbered Nginx- och compose-mallar och routa därefter till kommandon för tjänstens livscykel.

  1. Konfigurera Nginx Config Set med main- och main_location-blocken exakt som definierat i nodens värden.
  2. I Compose Template Build sätter ni docker-compose till den fullständiga YAML-mallen med uttryck som {{ $('Incoming API Hook').item.json.body.domain }}, {{ $('Incoming API Hook').item.json.body.username }} och {{ $('Incoming API Hook').item.json.body.password }}.
  3. Koppla Nginx Config Set → Compose Template Build → Service Command Router.
  4. I Service Command Router säkerställer ni att utdata är mappade till test_connection, create, suspend, unsuspend, terminate och change_package.
  5. För tjänsteåtgärder (Connectivity Test, Provision Service, Suspend Service, Resume Service, Terminate Service, Adjust Package) bekräftar ni att varje nod skapar ett sh-script som kommer att köras av Remote SSH Execute.

Steg 5: Konfigurera container- och appåtgärder (grupperade set-noder)

Dessa set-noder genererar shell-script för containerinspektioner, statistik, loggar och uppgifter på appnivå. De routas av switch-noderna och körs via SSH.

  1. För containerinfo verifierar ni att Inspect Container, Container Stats, Fetch Logs och Dependent Stats var och en tilldelar ett sh-fält med de tillhandahållna bash-skripten.
  2. För containerkommandon verifierar ni att Start Container, Stop Container, Attach Storage, Detach Storage, Retrieve ACL, Update ACL och Network Usage var och en producerar ett sh-script med uttryck som {{ $('Config Parameters').item.json.clients_dir }} och {{ $('Incoming API Hook').item.json.body.domain }}.
  3. För appåtgärder bekräftar ni att App Version Lookup, List App Users och Reset Admin Password bygger det scriptinnehåll som krävs för respektive kommandoscenario.

Tips: Eftersom detta workflow använder många set-noder (20+) bör ni behålla deras sh-värden intakta för att undvika att bryta nedströms SSH-körning.

Steg 6: Konfigurera fjärrkörning och svarsformatering

Alla script körs via SSH och normaliseras till ett konsekvent JSON-svar innan svar skickas till API-anroparen.

  1. Konfigurera Remote SSH Execute med Cwd satt till =/ och Command satt till {{ $json.sh }}.
  2. Inloggningsuppgifter krävs: Anslut era sshPassword-inloggningsuppgifter i Remote SSH Execute.
  3. Behåll körflödet från alla kommandonoder till Remote SSH Execute och därefter till Format Response Script.
  4. I Format Response Script behåller ni den medföljande JavaScript-koden för att tolka $json.stdout och returnera strukturerade status, message och data.
  5. Koppla Format Response Script till Webhook Reply och ställ in Respond With till allIncomingItems.

⚠️ Vanlig fallgrop: Om en set-nod inte tilldelar sh kommer Remote SSH Execute att köra ett tomt kommando och returnera oanvändbar output.

Steg 7: Testa och aktivera ert workflow

Validera webhook-routing, SSH-körning och svarsformatering innan ni aktiverar produktion.

  1. Klicka på Execute Workflow och skicka en POST-förfrågan till /webhook/docker-immich med en giltig server_domain och ett command som matchar en routerregel.
  2. Verifiera att Domain Match Check routar förfrågan parallellt och att rätt gren når Remote SSH Execute.
  3. Bekräfta att svaret formateras av Format Response Script och returneras av Webhook Reply med en status på success (eller ett tydligt felmeddelande).
  4. Om allt fungerar växlar ni workflowet till Active för att ta emot API-förfrågningar i produktion.
🔒

Lås upp fullständig steg-för-steg-guide

Få den kompletta implementeringsguiden + nedladdningsbar mall

Vanliga fallgropar

  • WHMCS-webhookens inloggningsuppgifter kan löpa ut eller ändras vid moduluppdateringar. Om saker slutar fungera, kontrollera först webhookens Basic Auth-credential i n8n och modulens endpoint-inställningar i WHMCS.
  • Om du använder Wait-noder eller extern rendering varierar processtiderna. Öka väntetiden om efterföljande noder fallerar på tomma svar.
  • Standardprompter i AI-noder är generiska. Lägg in din varumärkesröst tidigt, annars kommer du redigera output för alltid.

Relaterade arbetsflöden

Om du vill ha samma idé men mer fokuserad på containeroperationer (start/stop, statistik, nätverksanvändning) passar WHMCS + Docker: hands off container actions bra ihop med det här driftsättningsflödet.

För team som standardiserar en specifik app-utrullning är WHMCS + Docker: deploy Nextcloud without manual steps användbart när ”provisionering” betyder mycket mer än att starta/stoppa en container.

När din största smärta är supportchurn, inte initial driftsättning, hjälper WHMCS + Docker: handle tickets with fewer errors dig att minska de repetitiva ärendemönster som äter upp dagen.

Behöver du bredare livscykelkontroll bortom driftsättningsmallar? WHMCS + Docker: hands off provisioning and control är en stark följeslagare när du bygger en mer komplett automationsuppsättning för ”day 2 ops”.

Slutligen, om du specifikt försöker göra pausningar och återaktiveringar mer tillförlitliga (och mindre känslostyrda), är WHMCS + Docker: provisioning and suspends handled värd att lägga till tillsammans med det här arbetsflödet.


Snabbreferens:

Vanliga frågor

Hur lång tid tar det att sätta upp den här WHMCS Docker-automationen?

Cirka en timme om din SSH-åtkomst och WHMCS-modul är redo.

Behöver jag kunna koda för att automatisera WHMCS Docker-automation?

Nej. Du konfigurerar främst credentials, redigerar några parametrar och testar varje WHMCS-åtgärd en gång.

Är n8n gratis att använda för det här WHMCS Docker-automationsflödet?

Ja. n8n har ett gratis alternativ för egen hosting och en gratis provperiod på n8n Cloud. Cloud-planer börjar på 20 USD/månad för högre volymer. Du behöver också räkna med serverkostnader för din Docker-host (och eventuella betalda WHMCS-modulavgifter du redan har).

Var kan jag hosta n8n för att köra den här automationslösningen?

Två alternativ: n8n Cloud (hanterat, enklast setup) eller egen hosting på en VPS. För egen hosting är Hostinger VPS prisvärt och hanterar n8n bra. Egen hosting ger dig obegränsade körningar men kräver grundläggande serveradministration.

Kan jag anpassa det här WHMCS Docker-automationsflödet för olika Docker Compose- och Nginx-inställningar?

Ja, och det bör du sannolikt göra. Uppdatera värden i ”Config Parameters” som server_domain och kataloger, och anpassa sedan ”Compose Template Build” till din föredragna Compose-struktur och ”Nginx Config Set” till dina proxy-standarder. Vanliga anpassningar är att lägga till miljövariabler, byta lagringsvägar och sätta resursbegränsningar för specifika paket.

Varför misslyckas min WHMCS-anslutning i det här arbetsflödet?

De flesta fel beror på att Basic Auth inte matchar på webhooken, eller att domänen inte matchar och triggar vägen ”Respond Invalid Domain”. Kontrollera först WHMCS-modulens endpoint-URL och bekräfta sedan att webhook-credentialn i n8n matchar det WHMCS skickar. Verifiera därefter att arbetsflödets server_domain-parameter exakt matchar det WHMCS anropar (inklusive subdomän). Om du fortfarande sitter fast, titta på senaste webhook-körningen i n8n och jämför inkommande payload med det dina kommandoroutrar förväntar sig.

Hur många tjänsteåtgärder kan den här WHMCS Docker-automationen hantera?

Med en typisk n8n Cloud-plan kan du hantera tusentals körningar per månad, och egen hosting tar bort körningstaket (din server blir begränsningen). I praktiken är SSH-åtgärder flaskhalsen, så räkna med några förfrågningar per minut per Docker-host om du vill ha förutsägbar prestanda. Om du behöver mer, kör flera workers eller köa förfrågningar så att provisionering inte krockar med tunga logguttag.

Är den här WHMCS Docker-automationen bättre än att använda Zapier eller Make?

Oftast, ja. Zapier och Make är utmärkta för SaaS-till-SaaS-uppgifter, men SSH-drivna DevOps-flöden blir snabbt klumpiga, och routing med många grenar blir dyrt. n8n hanterar komplex växling (tjänstkommandon vs containerkommandon vs appkommandon) utan att göra din automation till en spaghettihärva. Egen hosting spelar också roll här eftersom du kan vilja att WHMCS-händelser och infrastrukturåtgärder stannar på dina egna servrar. Prata med en automationsexpert om du vill ha en snabb rekommendation för din stack.

När detta väl är på plats slutar WHMCS vara ”stället där kunder klickar på knappar” och blir systemet som faktiskt driver verkligheten för tjänsten. Arbetsflödet hanterar de repetitiva infrastrukturstegen, så att du kan fokusera på tillförlitlighet och tillväxt.

Kontakta oss

Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.

Våra tjänster Om Node Nordic
×

Använd mall

Få direkt tillgång till denna n8n-arbetsflödes JSON-fil

Kopiera och importera JSON-arbetsflödet i ditt n8n-arbetsflöde