🔓 Unlock all 10,000+ workflows & prompts free Join Newsletter →
✅ Full access unlocked — explore all 10,000 AI workflow and prompt templates Browse Templates →
Home › n8n › Workflow
January 22, 2026

WHMCS + Docker: provisioning and suspends handled

WHMCS + Docker: provisioning and suspends handled - n8n workflow automation template
Lisa Granqvist Partner Workflow Automation Expert
WHMCS + Docker: provisioning and suspends handled - n8n workflow automation template
Get a free AI assessment → Get a free AI assessment → ⬇️ Use template

WHMCS says a service is “suspended,” but the container is still happily running. Or provisioning fails, and now you’re hopping between WHMCS, SSH, and Docker commands trying to figure out what actually happened.

This WHMCS Docker automation hits hosting operators hardest, but support leads and DevOps folks feel it too. The outcome is simple: service actions in WHMCS consistently trigger the right Docker actions on the server, without manual logins.

You’ll see how the workflow receives commands, validates requests, runs the correct SSH scripts, and returns a clean response back to WHMCS so your team can move on.

How This Automation Works

The full n8n workflow, from trigger to final output:

n8n Workflow Template: WHMCS + Docker: provisioning and suspends handled

The Problem: WHMCS service actions don’t reliably match Docker reality

When WHMCS is your source of truth but Docker is where the service actually lives, tiny mismatches become daily fires. A “provision” button in WHMCS may require building a compose file, preparing Nginx config, setting ACL, mounting storage, and starting the container. Do that by hand and it’s slow. Do it under pressure and it’s error-prone. The worst part is the mental load: your team has to remember the right command order, the right server, and the right client directory every time. Miss one piece and you’re debugging at the exact moment the customer is watching.

It adds up fast. Here’s where it usually breaks down in real teams.

  • Provisioning becomes a “tribal knowledge” checklist that only one or two people can execute confidently.
  • Suspends and restores drift because WHMCS updates instantly, while Docker actions depend on someone running the right commands.
  • Support asks for logs and stats, but getting them means interrupting an engineer to SSH into production.
  • One wrong domain, mount path, or client directory can create a mess that takes about an hour to unwind.

The Solution: WHMCS triggers Docker actions through an n8n API backend

This workflow turns n8n into a controlled “service actions API” for your WHMCS Docker module. It starts with an incoming webhook call (from WHMCS/WISECP), then assigns and normalizes the request parameters so every command has the same shape. Next, it validates the domain to reduce accidental execution against the wrong target, and routes the request to the right action group (service actions, container actions, or app actions). From there, the workflow generates the appropriate Bash script content and executes it over SSH on a server that already has Docker installed. Finally, it parses the SSH output into a clean response and sends it back to WHMCS, so the billing platform can record a clear success or failure instead of a vague “module command error.”

The workflow starts when WHMCS calls the n8n webhook with a specific command like provision, suspend, restore, terminate, or fetch logs. n8n routes that command, runs the matching SSH-backed script, and responds with structured output (JSON or a readable string) for your module to consume. No tab-hopping.

What You Get: Automation vs. Results

Example: What This Looks Like

Say you handle about 20 service actions a week across provision, suspend, restore, and “please grab logs.” Manually, each one often means 10 minutes to find the right server, SSH in, run Docker commands, and paste results back into a ticket, so you’re burning roughly 3 hours weekly. With this workflow, the WHMCS action triggers the webhook in seconds, the SSH script runs in a minute or two, and the response comes back automatically. You still review edge cases, but the routine work mostly disappears.

What You’ll Need

  • n8n instance (try n8n Cloud free)
  • Self-hosting option if you prefer (Hostinger works well)
  • WHMCS to trigger module service actions.
  • Docker server (Linux) to run containers and compose stacks.
  • SSH credentials (create in n8n credentials manager)
  • Webhook Basic Auth (create in n8n, used by WHMCS)

Skill level: Intermediate. You’ll connect credentials, edit a few parameters (domain and directories), and be comfortable validating SSH access.

Don’t want to set this up yourself? Talk to an automation expert (free 15-minute consultation).

How It Works

WHMCS calls the webhook API. When a customer orders a service, misses a payment, or support triggers an action, WHMCS hits the “Incoming API Webhook” endpoint in n8n using Basic Auth.

Parameters get normalized and checked. n8n assigns values like server_domain, client directories, and mount defaults, then “Validate Domain” blocks bad targets and sends a 422 reply when something is off.

The workflow routes to the right command. A set of routers (service, container, and app) decide what should happen next: provision vs. suspend, start vs. stop, fetch logs vs. inspect stats, and so on.

SSH runs the actual Docker work. The “Remote SSH Runner” executes the generated scripts on your Docker host, then “Parse SSH Result” formats the output before “Webhook Response” returns it to WHMCS.

You can easily modify the Docker Compose template and Nginx config generation to match your product plans and customer requirements. See the full implementation guide below for customization options.

Step-by-Step Implementation Guide

Step 1: Configure the Webhook Trigger

Set up the entry point that receives API requests for Docker automation tasks.

  1. Add and open Incoming API Webhook.
  2. Set Path to docker-n8n.
  3. Set Response Mode to responseNode.
  4. Enable Authentication with basicAuth and keep Multiple Methods enabled.
  5. Credential Required: Connect your httpBasicAuth credentials.

Step 2: Define Global Parameters and Domain Validation

Initialize defaults and validate the incoming server domain before routing commands.

  1. Open Assign Parameters and set server_domain to d01-test.uuq.pl.
  2. Set clients_dir to /opt/docker/clients and mount_dir to /mnt.
  3. Set screen_left to {{ and screen_right to }}.
  4. Configure Validate Domain to compare {{$json.server_domain}} with {{$('Incoming API Webhook').item.json.body.server_domain}}.
  5. Ensure the false path of Validate Domain connects to 422 Invalid Domain Reply and returns the JSON body defined in that node.
⚠️ Common Pitfall: If the incoming server_domain doesn’t match Assign Parameters, the workflow returns the 422 Invalid Domain Reply response and no commands will run.

Step 3: Configure Parallel Routing for Command Types

After validation, the workflow routes commands in parallel based on the incoming command value.

  1. Confirm Assign Parameters connects to Validate Domain.
  2. Ensure Validate Domain outputs to Container Info Router, Container Command Router, App Command Router, and Route Service Setup in parallel.
  3. In Container Info Router, confirm rules use {{$('Incoming API Webhook').item.json.body.command}} for container_information_inspect, container_information_stats, and container_log.
  4. In Container Command Router, confirm rules use {{$('Incoming API Webhook').item.json.body.command}} for container_start, container_stop, container_mount_disk, container_unmount_disk, container_get_acl, container_set_acl, and container_get_net.
  5. In App Command Router, confirm rules use {{$('Incoming API Webhook').item.json.body.command}} for app_version, app_users, and change_password.
Tip: The parallel branches allow different command categories to execute simultaneously, so ensure command values are unique to avoid multiple branches triggering at once.

Step 4: Build Service Setup and Compose Artifacts

For create/change/unsuspend actions, the workflow prepares Nginx configuration and a docker-compose file before routing to service actions.

  1. Open Route Service Setup and keep the OR conditions for create, change_package, and unsuspend using {{$('Incoming API Webhook').item.json.body.command}}.
  2. In Prepare Nginx Config, set main to ignore_invalid_headers off; client_max_body_size 0; proxy_buffering off; proxy_request_buffering off;.
  3. Set main_location to # Custom header (with the trailing newline).
  4. In Build Compose File, set docker-compose to the full YAML template using expressions like {{$('Incoming API Webhook').item.json.body.domain}}, {{$('Assign Parameters').item.json.mount_dir}}, {{$('Incoming API Webhook').item.json.body.ram}}, and {{$('Incoming API Webhook').item.json.body.cpu}}.
  5. Confirm Build Compose File routes to Service Command Router.

Step 5: Configure Service and Container Actions (Grouped)

The workflow uses many set nodes to build shell scripts for different Docker service operations. Configure these nodes consistently and keep their outputs directed to SSH execution.

  1. Ensure Service Command Router routes to Test Host Connection, Provision Service, Suspend Service, Restore Service, Terminate Service, and Adjust Service Plan.
  2. Ensure Container Info Router routes to Inspect Container, Collect Container Stats, and Fetch Container Logs.
  3. Ensure Container Command Router routes to Start Container, Stop Container, Mount Storage, Unmount Storage, Retrieve ACL, Apply ACL, and Retrieve Network Stats.
  4. Ensure App Command Router routes to Get App Version, List App Users, and Update User Password.
  5. Verify each of these action nodes sets a sh field with the full bash script and uses expressions like {{$('Incoming API Webhook').item.json.body.domain}} and {{$('Assign Parameters').item.json.clients_dir}}.
⚠️ Common Pitfall: There are 20+ set nodes building shell scripts. Make sure each one outputs to Remote SSH Runner; missing a connection will cause the request to return without running the script.

Step 6: Configure SSH Execution and Response Parsing

All command scripts are executed remotely and normalized into a consistent API response.

  1. Open Remote SSH Runner and set Command to {{$json.sh}}.
  2. Set Working Directory to / (expression =/).
  3. Credential Required: Connect your sshPassword credentials.
  4. Verify that every action node connects to Remote SSH Runner, and Remote SSH Runner connects to Parse SSH Result.
  5. In Parse SSH Result, keep the JavaScript logic that parses $json.stdout into standardized status, message, and data.
  6. Confirm Parse SSH Result connects to Webhook Response with Respond With set to allIncomingItems.

Step 7: Test & Activate Your Workflow

Validate execution with test calls and then enable the workflow for production use.

  1. Click Execute Workflow and send a POST request to the Incoming API Webhook test URL with a valid server_domain and command.
  2. Confirm the execution runs through Validate Domain and then into the correct router branch based on command.
  3. Verify Remote SSH Runner returns output that Parse SSH Result converts into a status of success or error.
  4. Check the webhook response from Webhook Response to confirm you receive the expected JSON structure.
  5. Toggle the workflow to Active to enable production use.
🔒

Unlock Full Step-by-Step Guide

Get the complete implementation guide + downloadable template

Common Gotchas

  • Webhook Basic Auth credentials can expire or get changed during security cleanups. If calls start failing, check the n8n webhook node credentials and the WHMCS module config first.
  • If you’re using Wait nodes or external rendering, processing times vary. Bump up the wait duration if downstream nodes fail on empty responses.
  • Default prompts in AI nodes are generic. Add your brand voice early or you’ll be editing outputs forever.

Related Workflows

If your team also needs a clean “one-click app deploy” flow on top of basic service control, WHMCS + Docker: deploy Nextcloud without manual steps pairs well with this setup because it focuses on a specific product rollout, not just lifecycle actions.

For teams doing lots of stop/start and operational commands (especially during incidents), WHMCS + Docker: hands off container actions is a natural companion, since it leans into day-two operations like container control and quick checks.

When you want WHMCS to feel “hands free” from order to running service, WHMCS to Docker, hands free service deployments helps round out the bigger deployment story and reduces the number of manual handoffs between billing and infrastructure.

Need tighter end-to-end control, including plan changes and restores that don’t drift over time? WHMCS + Docker: hands off provisioning and control is worth using alongside this workflow so customer lifecycle actions stay consistent as you scale.

Finally, if you want the support side to get calmer (fewer “what server is this on?” mistakes), WHMCS + Docker: handle tickets with fewer errors complements this workflow by improving how your team handles service-related requests and evidence gathering.


Quick reference:

Frequently Asked Questions

How long does it take to set up this WHMCS Docker automation automation?

About an hour if SSH and WHMCS are already in place.

Do I need coding skills to automate WHMCS Docker automation?

No. You will mostly configure credentials and edit a few parameters. If you want to change the Bash scripts or routing logic, then some scripting comfort helps.

Is n8n free to use for this WHMCS Docker automation workflow?

Yes. n8n has a free self-hosted option and a free trial on n8n Cloud. Cloud plans start at $20/month for higher volume. You’ll also need to factor in server costs for your Docker host (and possibly a VPS if you self-host n8n).

Where can I host n8n to run this automation?

Two options: n8n Cloud (managed, easiest setup) or self-hosting on a VPS. For self-hosting, Hostinger VPS is affordable and handles n8n well. Self-hosting gives you unlimited executions but requires basic server management.

Can I customize this WHMCS Docker automation workflow for per-product Docker Compose templates?

Yes, and it’s one of the best reasons to use this approach. Update the values set in “Assign Parameters,” then tailor “Build Compose File” and “Prepare Nginx Config” so each WHMCS product or plan generates the right ports, volumes, limits, and proxy rules. Many teams also tweak “Adjust Service Plan” to handle upgrades and downgrades cleanly, without rebuilding everything. If you maintain templates in GitHub, you can pull the latest config before provisioning and keep changes tracked.

Why is my WHMCS connection failing in this workflow?

Most of the time it’s Basic Auth mismatch or the webhook URL changed. Check the “Incoming API Webhook” node credentials, then confirm WHMCS is sending the same username/password and hitting the correct path. If you’re seeing a domain-related failure, the “Validate Domain” node is doing its job, so compare the requested domain to your configured server_domain value. And don’t ignore permissions: if WHMCS can call n8n but SSH can’t run Docker commands, the workflow will still fail at the execution step.

How many service actions can this WHMCS Docker automation automation handle?

On n8n Cloud Starter, you can handle thousands of executions per month for typical hosting operations, and higher plans handle more. If you self-host, there’s no hard execution cap, but your VPS size and your Docker host performance become the limiting factors. In practice, most actions here run as a single SSH execution, so it scales nicely as long as you avoid huge batch operations during peak hours.

Is this WHMCS Docker automation automation better than using Zapier or Make?

Usually, yes. Zapier and Make are great for SaaS-to-SaaS automations, but this workflow leans on SSH execution, routing, and structured responses, which is more natural in n8n. You also get the option to self-host for unlimited runs, which matters when every suspend, restore, and log fetch counts as an execution. The bigger win is control: you can keep your scripts and security posture exactly how you want, instead of fighting a connector’s limitations. If your setup is very simple and you never need SSH, the other tools can be fine. Talk to an automation expert if you want help choosing.

Once this is running, WHMCS actions line up with what Docker actually did. That alone makes support calmer and provisioning a lot more predictable.

Need Help Setting This Up?

Our automation experts can build and customize this workflow for your specific needs. Free 15-minute consultation—no commitment required.

Talk to Automation Expert →

Lisa Granqvist

Workflow Automation Expert

Expert in workflow automation and no-code tools.

×

Use template

Get instant access to this n8n workflow Json file

Copy and import json workflow into your n8n workflow

💬
Get a free quote today!
Get a free quote today!

Tell us what you need and we'll get back to you within one working day.

Get a free quote today!
Get a free quote today!

Tell us what you need and we'll get back to you within one working day.