For 18 months, every product idea that landed in our backlog had the same first question attached: can we actually do this in the WHMCS template engine? The answer was usually no — or yes, but painfully, with a hook file glued onto a Smarty template glued onto a sidebar widget. Eventually we stopped asking. Last week we shipped V2 — a complete rewrite of the customer portal on Next.js 16 — because the cheapest path to the next fifty features was to stop fighting the template engine and own the surface ourselves.

This is what we changed, why we changed it, and what's next.

The reason we rebuilt

WHMCS is a billing system. It's a very good billing system. It's also been used by every budget host since 2010 as the entire customer surface — login, dashboard, invoices, support, server management — because nobody wanted to write a portal from scratch. We were no exception.

The problem is that WHMCS's templating language wasn't designed for a real frontend. Every interactive component is a hook file plus a Smarty template plus a custom JavaScript snippet plus careful CSS scoping. State management is handled by the back button. Sessions are tied to a cookie that has been quietly extended four times across as many versions. There's no concept of a "portal" as separate from the billing admin — every page render goes through the same monolithic entry point.

When we wanted to add a Telegram bot that mirrors the portal's notifications, the easiest path was to build it as a separate service. When we wanted browser-based VNC consoles, we stitched together a token proxy. When we wanted the cart to start provisioning a server before the customer's confirmation email arrived, we needed real session control. After enough of those workarounds, the pattern was clear: we were building a portal next to WHMCS, not inside it.

V2 is what happened when we accepted that and built it properly.

What's visibly different

The portal is one app now. Before V2, customers bounced between three surfaces — a marketing site on privatebyte.com, a billing admin on the WHMCS install, and a console microsite for VNC. After V2, everything from "view my invoice" to "open a VNC console on my server" lives behind one login at my.privatebyte.com. One URL, one session, one design.

Browser-based VNC is built in. No-VNC client embedded directly in the portal — no token-passing dance, no separate console window. Click Console on a server, the connection opens in the same tab. The proxy behind it is a small Node service running alongside the portal; it generates a one-time token, opens a websocket to SolusVM2's noVNC endpoint, and tears down the connection when you close the tab.

Deploys finish in under sixty seconds. This isn't new — our standard images have always been quick — but it's now visible end-to-end in the UI. The cart hands off to provisioning the moment payment clears, and the dashboard updates in real time as the VM boots, the network configures, and SSH comes online. By the time the welcome email lands, the server is already accepting connections.

A Telegram bot that does real work. Link your account once and the bot mirrors every billing event — invoice generated, payment received, service due — into your chat. From the same chat you can list your servers, check status, start/stop/restart, pull SSH details, request a password reset, or open a support ticket. It uses inline keyboards, not slash commands; the experience is closer to a banking app than a chatbot.

What's invisibly different

There's a lot going on behind the scenes we won't fully unpack here, but two pieces are worth pulling out — both are patterns we expect to keep using as the surface grows.

The notification pipeline is event-driven. Every state change inside WHMCS — invoice paid, ticket opened, service suspended — fires a PHP hook that POSTs to /api/telegram/notify with a webhook secret. The portal's notify endpoint then checks each linked customer's per-category preferences before dispatching to the Telegram Bot API. This sounds simple, and it mostly is. But the result is that every customer-visible event reaches the customer through a single, structured pipeline, with full opt-in / opt-out per category. The same pipeline is what lets us alert ourselves on operational incidents without the alerts looking different from customer notifications. Same channel, same format, different audience.

Sessions are durable, not just hot. The portal session lives in Redis for the hot path, but every state-shape change — login, 2FA verification, role update — is also appended to a JSONL audit file on disk. If Redis flushes, the next read reconstructs from the audit log instead of "log everyone out." This is the same pattern we use for newer features like account-modes (read-only and suspended states for accounts under investigation): Redis serves single-digit-millisecond reads, the audit log makes recovery boring. It costs us roughly 200 lines of code per feature and removes an entire class of incident.

What's the same

The fundamentals haven't changed. Every plan still includes 1 Gbps unmetered bandwidth, free DDoS protection, free backups and snapshots, free IPv4, a built-in firewall, custom ISO support, no port restrictions. None of that was the bottleneck — V2 is a bet on the fundamentals being right and the surface needing to catch up.

If you're already a customer, you don't need to do anything. Your services, billing, tickets, and balance are all the same. The portal you log into is just better.

What's next

We're not done. The roadmap from here:

  • OpenClaw, our AI-agent hosting product, is in WHMCS and the storefront is wired up. Live container provisioning + post-deploy automation is the last mile.
  • Cross-node backups, free on every plan. Most hosts charge $5–20/month for what amounts to a snapshot. We're designing this as a 3-2-1 architecture from day one — node-mesh + off-site tier with restic over SFTP — so it's actually a backup, not a snapshot pretending to be one.
  • A new landing page. V2 is the portal; the marketing site at privatebyte.com still uses the old template. That's next.
  • A blog you're already reading. This post is the first one. We'll publish here as things ship — engineering choices, infrastructure migrations, security incidents, product launches. Not on a schedule. When something is worth writing up.

If you want to follow along, link the Telegram bot — it's how we send release notes too — or check back here. If anything looks wrong on V2, open a ticket and a real person will reply.