Hosting setup in 60 seconds, not 24 hours

The 24-hour myth

Spin up a hosting plan at most providers and you'll see a familiar line in the confirmation email: "Your account will be activated within 24 hours." Some go further — 48 hours. A few cap it at "1 business day." Translation: someone in support has to log into WHM, fill out the form, click Create. Manually.

This used to be normal. cPanel's automation API has existed since the early 2000s, but plenty of resellers never wire it up. The cost is paid by every customer who clicks Pay on a Friday night and waits until Monday morning to actually use what they bought.

We don't like that. So we wired up the WHM API end-to-end on day one.

What you actually see

Place an order on GoCelerus. Pay (QRIS, USDT, or bank — your choice). Refresh the dashboard. Your cPanel account is live, your credentials are in your inbox, and the "Login to cPanel" button works. End to end, this takes about 60 seconds — most of which is the payment gateway confirming the transaction.

If the domain you ordered isn't pointed at our nameservers yet, that's fine. The cPanel account exists either way; you can upload files, set up email, and configure databases. DNS catches up later.

How it works

Behind the scenes, the path looks roughly like this:

1. Payment confirmed — Midtrans webhook lands, or admin marks a USDT/bank payment paid.
2. Event fired — PaymentSucceeded triggers ProvisionServiceOnPayment in the Laravel listener stack.
3. Job queued — ProvisionCpanelAccount picks it up. The job is idempotent: if the service is already active (retry, double-fire, scheduler hiccup), it returns immediately without calling WHM twice.
4. WHM API call — we hit createacct over WHM's JSON API with the plan, domain, and a freshly generated password.
5. Service activated — the row updates to active, customer gets the welcome email with login details and a one-click SSO link.

POST https://server.gocelerus.com:2087/json-api/createacct
  ?username=geco12345&domain=example.com&plan=shared-pro

The whole pipeline runs on a queue worker, not inside the web request, so even if WHM has a transient latency spike the customer doesn't see a spinner.

What this means for you

• No support ticket to start using what you paid for
• Self-service rebuild at /app/services/{id} if you typo'd the domain — no waiting on an agent
• Multiple services per order provision in parallel, not sequentially
• Free uptime monitoring kicks in automatically once the service is active (see the previous post for setup)

Side note: VPS and dedicated servers are still semi-manual in Phase 1 — we send the spin-up command immediately, but the activation window depends on the upstream node provider. KVM-node auto-provisioning is on the roadmap.

Why others still don't do this

In our experience, providers stick with the 24-hour window for three reasons:

1. Abuse review. They check every signup manually before activation. We do it programmatically — risk-score the email, IP, and payment method on the order itself, and decline before the API call if it looks bad.
2. Oversold servers. If a WHM box is at capacity, creating a new account is risky. We cap utilisation per node and route new orders to the next available server in the region.
3. Habit. Some teams never moved off the manual workflow because nobody pushed back.

We pushed back. Spin up a plan, watch it land in seconds, and don't look back.