Selling VPS or cloud servers through WHMCS is one of the higher-margin hosting businesses you can run. But it's also where I see the most provisioning failures, because cloud-server creation involves a lot more moving parts than spinning up a cPanel account.
I've built WHMCS VPS provisioning for Proxmox clusters, Virtualizor pools, SolusVM 1 and SolusVM 2, and a handful of cloud APIs (DigitalOcean, Linode, Vultr). Here's the model that works.
The three architectures you'll choose between
- Self-hosted virtualization (Proxmox / Virtualizor / SolusVM). You own the hardware, manage hypervisors, allocate IPs. Highest margin, most operational work.
- Cloud API resale (DigitalOcean / Vultr / Linode / Hetzner Cloud). You don't own hardware; you call their API and resell. Lower margin, lower ops.
- Hybrid. Self-host the popular regions, use cloud APIs for niche ones.
The WHMCS integration is similar across all three — pick a provisioning module that matches your underlying infrastructure.
Step 1 — Pick the right provisioning module
| Platform | WHMCS Module | Notes |
|---|---|---|
| SolusVM 1 | Built into WHMCS (legacy) | Mature but the platform itself is end-of-life. Migrate. |
| SolusVM 2 | Official SolusVM 2 module | Current generation. Different API. |
| Virtualizor | Softaculous-provided WHMCS module | Stable, well-maintained. |
| Proxmox | 3rd-party modules (ModulesGarden, etc.) | Several options; vet support quality. |
| DigitalOcean | 3rd-party modules + custom dev | DO doesn't ship one — you buy or build. |
| Vultr | 3rd-party modules | Same as DO. |
| OpenStack / KVM custom | Custom provisioning module | You write it. See my provisioning module guide. |
Step 2 — Configure your virtualization server in WHMCS
WHMCS Admin → Setup → Products/Services → Servers → Add New Server:
- Type: your virtualization platform (Virtualizor, SolusVM, etc.).
- Hostname: master node's hostname.
- Username / API key: per your platform's API docs.
- Secure / Port: HTTPS, custom port if your platform uses one.
Click Test Connection. If it fails, the issue is almost always: firewall, wrong API endpoint, or expired API token.
Step 3 — Create VPS plans
Plans should mirror what's actually buildable on your infrastructure:
- Resources: CPU cores, RAM GB, disk GB, bandwidth.
- OS templates: which Linux distributions you offer (Ubuntu LTS, Debian stable, AlmaLinux, Rocky Linux).
- Region: if you have multiple regions / nodes.
- IP type: shared / dedicated, IPv4 / IPv6.
In WHMCS:
- Setup → Products/Services → Products → Create New Product.
- Product Type: Dedicated/VPS Server.
- Module Settings: point to your virtualization platform. Map the WHMCS product to a specific virtualization plan ID + OS template ID.
- Add Configurable Options for things customers should choose at checkout: OS (dropdown of templates), region (dropdown of nodes), extra IPs (quantity-priced).
Step 4 — Network and IP management
This is the part that's different from cPanel hosting and often surprises people.
Self-hosted platforms (Virtualizor, SolusVM, Proxmox) have their own IP pool management. You upload the IPv4 ranges you own, the platform allocates one per VPS at creation. WHMCS doesn't manage this directly — the provisioning module just receives "the VPS was created with IP X.X.X.X" from the platform's API.
Pitfalls:
- IP pool exhaustion. Customer pays, creation fails because no IPs available. Monitor your pool capacity. Set up a Slack alert at <10% free.
- IP reputation drift. When a customer terminates and you reuse the IP, the next customer inherits whatever blacklist history exists. Hold IPs out of the pool for 7-30 days after release, check against Spamhaus before reusing.
- IPv6 mandatory. Many customers want IPv6. Make sure your platform allocates a
/64per VPS (or larger). IPv4-only is increasingly limiting.
Step 5 — OS templates and customer expectations
Templates are pre-built OS images that boot in seconds. Maintain them carefully:
- Ubuntu 22.04 LTS, Debian 12, AlmaLinux 9, Rocky Linux 9 cover 95% of demand.
- Update templates monthly (security patches baked in saves customer time).
- Strip pre-installed packages to the minimum — customers want a clean base.
- Provide cloud-init support so customers can pass SSH keys / user data at creation.
- Avoid offering ancient versions (CentOS 7 is EOL, Ubuntu 18.04 is past LTS) unless you've decided to support them explicitly.
Document your template policy on a public page. "We update templates monthly. We don't support OS versions past their upstream EOL." Saves support load.
Step 6 — Control panel access and SSH credentials
Customers expect to log in to a VPS management panel after provisioning. Two patterns:
- Direct panel access: customer logs in to Virtualizor's enduser portal at
cp.youraservice.comwith username/password issued at provisioning. - WHMCS-embedded: customer clicks "Manage VPS" in WHMCS client area, which uses SSO to drop them into the panel.
WHMCS's client-area integration via the module's ClientArea and ServiceSingleSignOn functions handles SSO. The customer never sees a separate login.
Step 7 — Billing for usage-based add-ons
If you sell extras (additional bandwidth, snapshots, backups), use Configurable Options or post-billing add-ons:
- Pre-purchased add-ons (e.g., +100 GB extra bandwidth/month) — Configurable Options, customer picks at checkout.
- Metered overage (customer uses 200 GB extra; bill them next cycle) — custom hook reads usage from your platform's API, adds line item to next invoice. Pattern shown in my SaaS billing guide.
Step 8 — Monitoring and alerts
VPS provisioning has more failure modes than shared hosting. Set up monitoring:
- Provisioning success rate — alert if <95% in any 24-hour window.
- Average provisioning time — alert if >5 minutes for templates that should be sub-1-minute.
- API health — UptimeRobot check on your virtualization platform's master API.
- IP pool free capacity — alert at <10%.
- Node CPU / RAM / disk pressure — your hypervisor's monitoring, integrated with your alerting.
How to verify the full flow
- From your customer-facing order page, place a real test order. Pay (or use a coupon).
- Watch the WHMCS Module Log: Utilities → Logs → Module Log. The provisioning call should succeed within your expected time window.
- Confirm the VPS exists in your virtualization platform's admin UI.
- SSH into the VPS using the credentials WHMCS sent the test customer.
- From the WHMCS client area as the test customer, click the "Login to Panel" button — SSO should land you in the VPS management UI.
- From admin: Suspend the service. Confirm the VPS is suspended (typically paused or shut down) in the platform.
- Unsuspend. Confirm running.
- Terminate. Confirm the VPS is destroyed and its IP returned to the pool (after holding period).
Common pitfalls
"Provisioning succeeds but customer can't log in." Either: the password WHMCS sent isn't the one set on the VPS (race condition during template apply), or the network isn't fully up yet. Most platforms have a "ready" callback or status field — your module should wait for it before sending the welcome email.
"Suspending doesn't disconnect customer's running services." Some platforms only "stop billing" on suspend without actually shutting down the VPS. Configure your module to also issue a shutdown command on suspend.
"Customer over-uses bandwidth and we don't know until end of month." Pull usage from your platform's API on a daily schedule, write to your own table, alert when usage exceeds some % of their plan.
"Customer asks to switch OS — does WHMCS support reinstall?" Yes via the module's ChangeOS or similar function (varies by platform). Expose it as a button in the client area; customers love the self-service.
"Provisioning to specific region fails randomly." Region capacity. Some platforms don't expose capacity status until provisioning fails. Add a daily check that probes capacity across regions and disables order forms for full regions.
My take — VPS business operational discipline
- Templates are a product. Keep them updated, polished, with sensible defaults. Customers' first impression is the first SSH login.
- IP reputation is real money. Hold released IPs, check against blacklists before reissuing.
- Monitor your platform's API like it's the most critical service in your stack — because it is.
- Document your abuse policy publicly. VPS customers will run things you didn't expect. Your support team needs explicit rules.
- Provide a status page for your nodes / regions. Customers should not have to file a ticket to learn "yes, node A is down right now."
Going further
- WHMCS VPS provisioning overview
- Virtualizor / SolusVM / Proxmox module documentation — vendor-specific
- My provisioning module guide — when you need to write your own
I architect WHMCS-driven VPS / cloud hosting businesses end-to-end — virtualization choice, provisioning modules, IP management, monitoring. Tell me what you're building and I'll send a quote in 24 hours.