Sell isolated workspaces from WHMCS or Blesta

Run one server, resell isolated workspaces to your own customers — provisioned automatically from WHMCS or Blesta, each customer walled off from every other, on one flat monthly price instead of a per-seat toll.

How provisioning actually works

1. Customer orders a plan in WHMCS or Blesta

   Your product's configuration options carry the caps — disk, RAM, CPU, burst, upload/download speed, monthly upload allowance — the same fields you already fill in for any other hosting product.

2. The module calls Cresdock's provisioning API

   A versioned REST API (/api/v1) creates the account with those caps applied. Calls are idempotent — retrying an order that already provisioned adopts the existing account instead of erroring or duplicating it.

3. The customer gets an invite, never a password you handled

   Invite mode emails a set-your-own-password link directly to the customer. Their password is never generated by, or transmitted through, your billing system.

4. Suspend, unsuspend and terminate follow your billing events automatically

   A missed payment suspends the workspace; catching up unsuspends it; cancellation terminates it — wired to the same hooks WHMCS/Blesta already fire for every other product.

The WHMCS module

The WHMCS seedbox module is a normal server module: you attach it to a product, and account creation, suspension, unsuspension and termination follow your existing order flow with nothing extra to click. The plan's limits — disk, RAM, CPU, speeds, monthly upload allowance — live in the product's configuration options, so changing a plan in WHMCS changes what the workspace gets. Your staff never leave the WHMCS admin they already use. The setup guide walks the whole thing — fetching the free module, the ten-minute install, and what runs by itself once it’s in.

The Blesta module

The Blesta server module works the same way: a module plus an admin plugin for selling and managing workspaces, with the same automatic create, suspend, unsuspend and terminate lifecycle driven by your billing events.

Built for a full server, not just a happy path

• Queues instead of failing. When the server is at capacity, new orders queue (oldest first) and activate the moment a slot frees up — or you can force one through immediately if you choose to override it.
• One trial per customer, enforced. A second trial order from someone who already has one running is held back automatically, so trial abuse doesn't quietly eat capacity meant for paying customers.
• Customers aren't left guessing. Anyone queued gets an email with their position and an estimated activation time; trial customers get a reminder before their trial ends.
• Nothing lingers in limbo. A terminated service that never got fully cleaned up flips to cancelled automatically after a short grace window.

Why the isolation matters for a resale business

This is the part a generic Docker panel doesn't have an answer for. Every customer's apps run in their own containers on their own private network — not a shared one with permissions hoping to hold. One tenant's app cannot reach another tenant's files or unauthenticated ports, because there is no shared network path between them to begin with. That is the difference between "we configured this carefully" and "this is architecturally not possible" — the second one is what you want to be able to tell a customer who asks.

See also: Pricing  ·  Setup guide  ·  The seedbox vertical your customers will ask for  ·  vs QuickBox  ·  vs Swizzin  ·  vs Cloudron