WHMCS · provisioning module
An order in WHMCS becomes a machine in KLYRN.
The module holds no hypervisor code. Every order lands on the same engine the customer panel uses, so placement, addresses and first boot are decided in one place and cannot drift between two copies.
What each button does
The WHMCS function on the left, and what happens in KLYRN.
- Test ConnectionReports what it found, not just "ok": a controller with no enabled plan, no image or no connected node is named, so it is fixed now and not at the first order.
- CreateBuilds the machine on the plan and system the product names. If KLYRN already has this service, it links to it and builds nothing.
- SuspendShuts the guest down, or cuts its network and leaves it running, by your policy. It never touches a disk.
- UnsuspendReverses what was actually done, not what the setting says today.
- TerminateThe only destructive call, and the only one that sends an explicit confirmation.
- Upgrade or downgradeResizes the machine the customer already has: same machine, same address, same console.
- Usage updateDisk and transfer per service, for billing overages.
- Log in to the panelA single-use link that lasts ninety seconds takes the customer from WHMCS into their machine.
- ReinstallThe same machine and address with a new operating system, from an admin button.
- Retry provisioningRecovers a paid order whose build failed, without a second order.
Three ways billing goes wrong, closed
Built for the day something is retried.
- A double click cannot build two machines. WHMCS retries: a cron times out, an admin presses Create twice, two workers fire the same call. Every changing call carries a key made from the WHMCS service id, and KLYRN holds a second guard on the service id itself.
- Migration day does not create a second estate. Point WHMCS at a freshly migrated KLYRN and press Create on every service, and each one links to the machine that is already running. Adoption has its own button with a preview that writes nothing: it shows the WHMCS service, the old server and the KLYRN machine on one line.
- Suspension never destroys. Power off, or network isolate, set for the whole provider or per product. KLYRN records which one was used, so changing the policy while customers are suspended leaves nobody powered off with their network already restored.
- The token can do one job. The module uses an API token with the provision scope only. It cannot list your compute nodes, open a console or install a licence, so a leaked billing credential cannot either.
Setting it up
Four steps, all in screens you already know.
- Copy the module's
klyrnvmfolder into themodules/serversdirectory of your WHMCS. - In KLYRN VM, under Settings, API tokens, create a token with the provision scope and nothing else.
- In WHMCS, add a server of type KLYRN VM: the controller's hostname, port 8443, the token as the password. Press Test Connection.
- On each product, set the Plan and Operating system options to the names KLYRN uses. The provisioning catalogue lists them.
Read this before relying on it
What is proven, and what is not.
- Proven: every function, against a real controller. The module was driven by a harness that loads it unmodified and calls each function with WHMCS-shaped parameters, against a real KLYRN VM controller with real machines behind it. That covers its logic, its requests, its retry keys and every endpoint it calls.
- Not proven: inside a running WHMCS. No WHMCS installation was used for that test. So it is not yet shown that WHMCS calls these functions with exactly these parameters, or that its automation cron drives them as expected. Try it on a test product before a live one.
Not on WHMCS? There is an API.
Everything the panel does goes through it, with tokens that carry only the scopes you give them.