The CyberPanel WHMCS module, and the alternative

If you run WHMCS and you want to sell OpenLiteSpeed hosting, you go looking for a CyberPanel WHMCS module. Measured on 21 August 2026, the results for that search are a GitHub repository maintained by an individual, and a community forum thread.

That is not a criticism of anyone's work. It is a description of a gap: a piece of software that sits between your invoices and your customers' websites, and that most hosters find as a side project rather than as a product.

This page is about what such a module can do, what it structurally cannot, and what a different shape of solution looks like. The first part matters most, because the ceiling is not the module. It is CyberPanel's API.

The ceiling: what CyberPanel's API allows

Measured against CyberPanel 3.0, not read from documentation. Any module (the one on GitHub, one you write yourself, or the one described further down) is bounded by all of them.

Creating a site answers before it knows the outcome

createWebsite returns in about three seconds with createWebSiteStatus: 1. That is not a verdict; it means the work has been started. The endpoint launches a background command and returns immediately. Real progress lives in a status file that has to be polled separately.

Measured with deliberately bad input:

Only the shape of the domain and email is validated up front. A module that trusts the first answer will mark a WHMCS order as active for a site that was never created, and the customer receives welcome credentials for something that does not exist.

Polling that status file has two further catches. Reading a completed status deletes it, so one poll too many turns a finished creation into a permanent "still working". And the status call sits on the part of CyberPanel's API that refuses every administrator not literally named admin.

The whole creation takes about fifty seconds, of which roughly twenty-eight are an SSL attempt CyberPanel makes unconditionally. The API overrides that flag whatever you send. Any module needs a timeout that accommodates it.

Changing package changes a database field

changePackageAPI returns in about 270 milliseconds and the panel shows the new name. Measured from inside the server afterwards, with a package carrying different limits: the disk quota was unchanged (soft 0, hard 0) and the vhost configuration still carried the old package's memory and process limits.

Nothing was applied. So a WHMCS upgrade order can complete, invoice, and change the name in the panel while the customer's actual limits are exactly what they were. No module can fix this. The endpoint's entire implementation is a field update.

Suspension does not lock the account

CyberPanel suspends a site by rewriting its vhost to a suspension page and restarting the web server. The unix user is not locked; FTP, mail and databases keep working. If you suspend for non-payment, your customer still has their mail and their database. That may be exactly what you want, but it should be a decision, not a surprise.

There is a sharper edge too: the implementation is if state == "Suspend": … else: <resume>, with no validation. Measured: sending "suspend" in lowercase reactivated a suspended site and reported success. Any module should hold those two values as constants, never assemble them from a variable.

There is no usage data

Bandwidth is calculated by CyberPanel and then discarded before it reaches any listing. Disk usage comes from a cache on the website record which is empty on a new site, so the value falls back to zero, and a zero from an empty cache is indistinguishable from a site that uses nothing.

WHMCS has a usage-collection hook that expects disk and bandwidth figures. On CyberPanel there is nothing honest to put in it: a module that fills it in anyway is reporting a default, not a measurement.

API access is off, and the check order hides why

On a fresh CyberPanel the API is disabled, including for the main administrator, and the flag is checked before the password, so with it off a correct password and a wrong one return the identical API Access Disabled. The first-run failure of every module for this panel looks like a credentials problem and is not.

What that means for a module

None of the above is fixable inside a WHMCS module, because none of it is a module problem. What differs between modules is how honestly they handle it:

• Does it poll the creation status, or trust the first answer?
• Does it read the status once and record the outcome, or poll until it accidentally deletes the result?
• Does it tell you that a package change did not apply anything?
• Does it leave the usage hook empty, or fill it with zeros that look like data?
• Does it say "API access is switched off" instead of "invalid credentials"?

Those are the questions to ask of any module you are considering. They are answerable by reading the code, and they matter more than the feature list. There is one more, about you rather than the code: who maintains it in eighteen months? A provisioning module is on the critical path of every order you take.

The alternative: a provisioning layer, not a panel module

Provibr sits between your billing system and your infrastructure. It is not a WHMCS module for CyberPanel; it is a provisioning platform that speaks to CyberPanel, and that WHMCS talks to through one module regardless of what is underneath.

The practical difference:

Two rows deserve expanding, because they are the honest ones.

Cost. The module is free and Provibr is not. Provibr charges for the capacity you reserve (how many hosting accounts you may run at once) at a tiered unit price that falls as the count rises. What you charge your own customers stays entirely yours. If you have twelve CyberPanel sites and no plans to grow, a free module is the right answer.

Same limits, different honesty. Provibr does not repair CyberPanel's package change, does not invent usage figures, and does not lock a suspended account. It cannot: those are properties of the panel. What it does is refuse to pretend otherwise.

How it fits into WHMCS

One module, installed as a plain zip in modules/servers/. In WHMCS you add a server pointing at Provibr with an API key, then point one WHMCS product at one Provibr web plan. A paid order creates the account, a suspension suspends it, a termination removes it. Your customer keeps one account, one invoice and one login.

The API key carries scopes, and what it may actually do is the intersection of those scopes and the permissions of the member it belongs to, so a key can only ever narrow access, never widen it. Withdraw a permission from a colleague and every key of theirs becomes narrower on the next request, without anyone revoking anything.

If you do not run WHMCS, the same operations are available over the REST API: one key, one base URL. Anything that touches a machine answers "accepted" with a command to follow, because your infrastructure is only reachable through the agent inside your own network. Reads answer immediately.

When the module is the better choice

Being straight about it: if CyberPanel is the only panel you run, you already have WHMCS, your volume is small, and you are comfortable reading PHP when something breaks, then a module is less machinery and no monthly cost. The limits at the top of this page apply to both options equally.

The case for a layer above it starts when you run more than one panel, when you want the credentials off your WHMCS host, when something other than WHMCS has to place orders, or when you want the provisioning path to be someone's product rather than someone's weekend.

Provibr runs its control panels, hypervisors and game panels side by side today. They share one inventory, one permission model and one activity trail. You do not have to choose between CyberPanel and everything else.