🔓 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: hands off container actions

WHMCS + Docker: hands off container actions - n8n workflow automation template
Lisa Granqvist Partner Workflow Automation Expert
WHMCS + Docker: hands off container actions - n8n workflow automation template
Get a free AI assessment → Get a free AI assessment → ⬇️ Use template

You know the drill. A client pings you because their service is “down,” and suddenly you’re SSH’d into a server, typing the same Docker commands you typed yesterday, hoping you don’t hit the wrong container this time.

Hosting business owners feel it when tickets spike. Ops leads feel it during maintenance windows. Even a solo WHMCS admin ends up babysitting restarts, log pulls, and “quick checks.” This WHMCS Docker automation turns those repeat tasks into a reliable API you can trigger from WHMCS.

This workflow gives your WHMCS module a predictable back end in n8n, runs predefined Docker actions over SSH, then returns clean results to WHMCS. You’ll see what it does, what you need, and where teams usually trip up.

How This Automation Works

The full n8n workflow, from trigger to final output:

n8n Workflow Template: WHMCS + Docker: hands off container actions

The Problem: Manual Docker “Fixes” Don’t Scale in WHMCS

WHMCS is great at selling and managing services, but it’s not the place you want humans doing infrastructure work from memory. The painful part isn’t a single restart or log fetch. It’s the pile-up. One client needs a restart, another needs stats, another needs a mount fixed, and now you’re juggling container names, paths, and “which server was this on?” context switching. A small slip (wrong container, wrong host, wrong command) becomes downtime, data loss, or a messy ticket thread that never really closes.

It adds up fast, especially once you have more than a handful of active services.

  • Every “quick SSH check” steals 10 minutes, then pulls you into 30 more.
  • Different techs run slightly different commands, which means inconsistent outcomes and harder troubleshooting later.
  • Logs and stats get copied into tickets manually, so details are missed or pasted from the wrong service.
  • Provisioning changes (plan changes, suspends, resumes) become risky because they’re done under pressure.

The Solution: WHMCS Triggers, n8n Executes, Docker Responds

This workflow acts like an API “control room” between WHMCS and your Docker server. WHMCS (or a companion module like the Docker MinIO WHMCS module) sends a command to a secured n8n webhook. n8n validates the request, checks that the request is meant for the right server domain, and routes the command to the correct action. Then it connects to the Docker host via SSH and runs a predefined Bash script for that task. Finally, it formats the output into a consistent response (often JSON) and returns it to WHMCS so the module can display status, logs, or results without guesswork.

The workflow starts at an incoming webhook with Basic Auth. From there it sets base parameters (like server domain and directory paths), gates the action type, and uses routers to decide which script to run. The SSH runner executes the script, then a response formatter standardizes what WHMCS receives.

What You Get: Automation vs. Results

Example: What This Looks Like

Say your team handles 20 “container actions” a week from WHMCS tickets: restarts, fetching logs, checking stats, mounting a volume, that kind of thing. Manually, even a careful tech might spend about 10 minutes per action between SSH, finding the right container, running commands, and pasting results back, so that’s roughly 3 hours a week. With this workflow, the action is triggered from WHMCS in about a minute, the SSH execution happens in the background, and the response comes back formatted. You still review edge cases, but the busywork mostly disappears.

What You’ll Need

  • n8n instance (try n8n Cloud free)
  • Self-hosting option if you prefer (Hostinger works well)
  • WHMCS to trigger actions from client/service events
  • Docker host where containers and compose live
  • SSH credentials (create on the Docker server user)

Skill level: Intermediate. You’ll be comfortable creating credentials in n8n and adjusting a few server-specific parameters (domain, directories, and scripts).

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

How It Works

A secured webhook receives the command. WHMCS calls the “Incoming Webhook Endpoint” with Basic Auth. That request includes the action type (like start, stop, logs, stats, provision, suspend) and the service context.

Requests get validated and normalized. The workflow sets base parameters first, then checks that the server domain matches what you expect. If it doesn’t, it returns a clear 422-style response instead of doing something dangerous on the wrong host.

The correct script is selected and executed. Routers split traffic into container commands (start/stop/mount/unmount/logs/stats/ACL/network stats) and service commands (provision, suspend, resume, terminate, change plan). n8n then generates the relevant Bash script in a dedicated node and runs it through the SSH runner against the Docker server.

Results are formatted for WHMCS. The workflow turns raw command output into a predictable response, then replies to the original webhook call. WHMCS gets consistent logs, stats, inspect output, or confirmation messages that you can store, display, or attach to tickets.

You can easily modify the Docker Compose template and nginx configuration to match your product. See the full implementation guide below for customization options.

Step-by-Step Implementation Guide

Step 1: Configure the Webhook Trigger

This workflow starts with a secured webhook that receives container management commands.

  1. Add the Incoming Webhook Endpoint node and set Path to docker-minio.
  2. Set Response Mode to responseNode and enable Multiple Methods.
  3. Set Authentication to basicAuth.
  4. Credential Required: Connect your httpBasicAuth credentials to Incoming Webhook Endpoint.
⚠️ Common Pitfall: The webhook expects a JSON body with fields like command, domain, username, password, disk, ram, and cpu. Missing fields will break downstream scripts.

Step 2: Set Base Parameters and Validate Domain

Base parameters are centralized and used across all container scripts, and a domain validation gate protects the API.

  1. In Base Parameter Set, set server_domain to your identifier (currently [YOUR_ID]), clients_dir to /opt/docker/clients, and mount_dir to /mnt.
  2. Keep screen_left as {{ and screen_right as }} for Docker stats templating.
  3. In Domain Match Check, confirm the comparison uses {{ $json.server_domain }} equals {{ $('Incoming Webhook Endpoint').item.json.body.server_domain }}.
  4. Route invalid domains to 422 Domain Error Reply so the API returns the configured JSON error payload.
Tip: Update [YOUR_ID] in Base Parameter Set to your actual server domain ID before testing.

Step 3: Configure Parallel Routing for Commands

After validation, the workflow fans out into multiple routing branches to handle container info, container actions, MinIO actions, and service actions.

  1. Ensure Domain Match Check outputs to Container Info Switch, Container Command Router, MinIO Command Switch, and Action Type Gate in parallel.
  2. In Container Info Switch, confirm routes for container_information_inspect, container_information_stats, and container_log are based on {{ $('Incoming Webhook Endpoint').item.json.body.command }}.
  3. In Container Command Router, verify outputs for container_start, container_stop, container_mount_disk, container_unmount_disk, container_get_acl, container_set_acl, and container_get_net.
  4. In MinIO Command Switch, ensure app_version routes to App Version Script and app_users routes to List Users Script.
  5. In Action Type Gate, confirm the create, change_package, and unsuspend conditions route to Nginx Config Builder, and other commands route to Service Command Router.

Domain Match Check outputs to both Container Info Switch and Container Command Router and MinIO Command Switch and Action Type Gate in parallel.

Step 4: Build Templates and Command Scripts

This workflow builds Docker Compose and Nginx templates, then creates shell scripts used by the SSH executor. There are 20+ set nodes; configure them by function rather than individually.

  1. In Nginx Config Builder, keep the prefilled values for main, main_location, console, and console_location (these are injected into scripts later).
  2. In Compose Template Builder, verify the Docker Compose template uses expressions like {{ $('Incoming Webhook Endpoint').item.json.body.domain }} and {{ $('Base Parameter Set').item.json.mount_dir }}.
  3. Ensure Compose Template Builder flows into Service Command Router to support create, suspend, resume, terminate, and plan change operations.
  4. Review the script-building set nodes that feed Remote SSH Runner: Start Container Script, Stop Container Script, Provision Container Script, Suspend Service Script, Resume Service Script, Terminate Service Script, Change Plan Script, Mount Volume Script, Unmount Volume Script, Retrieve ACL Script, Apply ACL Script, Network Stats Script, Compose Inspect Script, Container Stats Script, Fetch Logs Script, App Version Script, and List Users Script.
⚠️ Common Pitfall: Many scripts rely on {{ $('Base Parameter Set').item.json.clients_dir }} and {{ $('Base Parameter Set').item.json.mount_dir }}. If those paths are wrong, all SSH actions will fail.

Step 5: Configure Remote Execution and Responses

All command scripts are executed over SSH and normalized into a standard API response.

  1. In Remote SSH Runner, set Command to {{ $json.sh }} and CWD to /.
  2. Credential Required: Connect your sshPassword credentials to Remote SSH Runner.
  3. Ensure all script nodes route into Remote SSH Runner, which then flows to Format Response Script.
  4. Keep Format Response Script in runOnceForEachItem mode to wrap outputs into {status, message, data} JSON.
  5. Return the final response through Webhook Success Reply with Respond With set to allIncomingItems.

Step 6: Test & Activate Your Workflow

Verify the webhook, routing, and SSH execution before enabling production use.

  1. Click Execute Workflow and send a test POST request to Incoming Webhook Endpoint with a valid JSON body and correct server_domain.
  2. Confirm that Domain Match Check routes to the correct branch and that one of the script nodes sends a command to Remote SSH Runner.
  3. Verify the response is normalized by Format Response Script and returned by Webhook Success Reply with a status of success.
  4. When tests succeed, toggle the workflow to Active to accept production webhook calls.
🔒

Unlock Full Step-by-Step Guide

Get the complete implementation guide + downloadable template

Common Gotchas

  • Webhook Basic Auth credentials can expire or get rotated. If calls suddenly fail, check the n8n credential used by the Incoming Webhook Endpoint first, then confirm WHMCS is sending the updated value.
  • If you’re using Wait-style timing elsewhere or the Docker host is under load, SSH execution time can vary. When downstream nodes return empty output, the fix is often to increase timeouts on the SSH command and avoid assuming “instant” responses.
  • SSH permissions are usually the real culprit when scripts fail. Make sure the SSH user can run Docker commands (often by being in the docker group) and can read/write the directories you set for clients_dir and mount_dir.

Related Workflows

If your team also needs to automate the full “new service” journey, not just container actions, WHMCS to Docker, hands free service deployments is a natural companion because it leans more into end-to-end deployment flow.

For support-heavy setups, pairing this with WHMCS + Docker: handle tickets with fewer errors helps you close the loop so ticket updates stay consistent with what actually happened on the server.

When you’re selling specific apps and you want fewer “please install this” back-and-forth messages, WHMCS + Docker: deploy Nextcloud without manual steps is a good add-on because it’s tuned for an application deployment outcome.

Need broader lifecycle control beyond start/stop/logs? WHMCS + Docker: hands off provisioning and control fits well when you want one operational surface area for more actions across your catalog.

Finally, if suspends and resumes are your biggest time sink (and honestly, they often are), WHMCS + Docker: provisioning and suspends handled goes deeper on the policy-driven side of service enforcement.


Quick reference:

Frequently Asked Questions

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

Plan on about 1 hour if your SSH and WHMCS details are ready.

Do I need coding skills to automate WHMCS Docker automation?

No. You’ll mostly be configuring credentials and editing a few parameters and scripts that are already laid out for you.

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 your server costs (and any paid WHMCS module licensing you use).

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 provisioning a different Docker app than MinIO?

Yes, but you’ll want to change the Compose Template Builder content and the Provision Container Script so they generate the right docker compose configuration for your app. Many teams also adjust the Nginx Config Builder so the proxy matches their domain pattern and headers. If you need different actions, you can add a new route in the Container Command Router or Service Command Router, then connect it to a new “script” node that feeds the SSH runner.

Why is my WHMCS connection failing in this workflow?

Usually it’s Basic Auth not matching what WHMCS is sending. Check the webhook credentials in n8n, then confirm the module’s endpoint URL and auth values. The next most common issue is the Domain Match Check blocking requests because server_domain doesn’t match the domain in the payload.

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

If you self-host n8n, there’s no hard execution limit; it mainly depends on your VPS size and how busy the Docker host is.

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

For Docker work, n8n is usually the better fit because it’s comfortable with multi-branch routing, SSH execution, and structured responses, all in one workflow. Zapier and Make can trigger webhooks, sure, but SSH-style infrastructure actions tend to feel bolted on. Another factor is control: self-hosting n8n keeps your operations inside your environment, which matters for hosting providers. Cost can be simpler too, because you’re not paying extra for every branch or every “advanced” step. If you’re torn, Talk to an automation expert and map it to your ticket volume and risk tolerance.

Once this is in place, Docker actions stop being a “who can SSH right now?” problem. The workflow handles the repetitive work, and your team gets back to higher-value support and operations.

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.