For 18 months, every product idea that landed in our backlog had the same question attached: can we actually do this inside 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, glued onto a custom JavaScript snippet. 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 customer surface ourselves.

This is what changed, why we changed it, and what comes next.

The reason we rebuilt

WHMCS is a billing system. It is a very good billing system. It has also been used by hosting companies for years as the entire customer surface — login, dashboard, invoices, support, server management — because nobody wanted to write a proper portal from scratch. We were no exception.

The problem is that WHMCS was never designed to be a modern frontend. Every interactive component becomes a stack of templates, hooks, custom scripts, and careful styling work. Simple features often become harder than they should be. State, navigation, and user experience all have to work around a system that was built primarily for billing, not for a modern product interface.

When we wanted richer customer notifications, we had to work around the limits of the existing surface. When we wanted browser-based server access, we had to build around the portal instead of inside it. When we wanted faster provisioning feedback after checkout, we needed more control over the user journey. After enough of those workarounds, the pattern was clear: we were not extending WHMCS anymore. We were building a portal next to 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 moved between separate surfaces — the marketing site, the billing area, and server management tools. After V2, everything from viewing an invoice to managing a server lives behind one login at my.privatebyte.com. One URL, one session, one design.

Browser-based console access is built in. Server console access is now available directly inside the portal. No separate console microsite, no awkward handoff between interfaces. Click Console on a server and the session opens inside the same customer experience. Simpler for customers, cleaner for us to maintain.

Deploys are easier to follow. Our standard images have always been fast — what changed is visibility. The checkout and provisioning flow now feels connected. Once payment clears, the portal shows the server moving through its deployment stages instead of leaving customers guessing. By the time the welcome email arrives, the server is usually ready to use.

The Telegram bot does real work. Link your account once and the bot mirrors important billing and service events into Telegram — invoice updates, payment confirmations, service reminders, ticket updates. From the same chat you can view servers, check status, perform basic power actions, request login details, reset passwords, or open a support ticket. Inline buttons rather than slash commands; the experience is closer to a banking app than a chatbot.

Proxies are now in the storefront. PrivateByte is no longer just compute. Residential, datacenter, and mobile proxy products are now available through the same dashboard as your cloud services — usage-based billing, one account surface for invoices and access, country pinning via password suffix or request header. A routing engine sits in front of multiple upstream providers and picks the right one for each target. The mobile tier carries real carrier IPs at consumer prices. Instead of treating proxies as a separate product bolted onto the side, V2 brings them into the same customer experience as everything else.

Green Credits when your VM is off. Most providers bill the same whether a VM is actively running or powered down. We don't. When an eligible VM is stopped, it accrues credit toward your next invoice; restart it when you need it. The system includes a minimum off-time threshold and a per-cycle cap so the model stays sustainable — but the principle is simple. Customers should benefit when they reduce active resource usage, not be billed identically as if they hadn't.

What's invisibly different

There's a lot going on behind the scenes, but the important change is simple: V2 gives us a proper platform layer.

Customer-facing events move through a structured notification system. Billing updates, service changes, support updates, and operational messages are now handled consistently across the portal and Telegram. Customers control what they receive. We keep the format predictable. Future products plug into the same system without each one needing its own notification logic.

Session handling has been redesigned to be resilient, not just fast. The portal now treats authentication and account state as core infrastructure, not as something bolted onto page templates. That gives us a cleaner base for features like role-based access, account controls, security reviews, team access, and future enterprise functionality.

The technical details matter, but the outcome matters more: fewer brittle workarounds, fewer disconnected services, and a platform that can keep growing without collapsing under its own glue code.

What's the same

The fundamentals haven't changed. Plans still include unmetered bandwidth, DDoS protection, daily automated backups (kept for 7 days), IPv4, firewall controls, and custom ISO support. 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 unchanged. The portal you log into is just better.

What's next

We're not done. The roadmap from here:

  • Sub-60-second Linux deploy as a guarantee. "Deploy in 60 seconds" is on the homepage. Most providers approximate it; we built ours to be literal. If we miss our claim on a qualifying deploy, the credit applies automatically.
  • OpenClaw on PrivateByte. OpenClaw is a third-party AI-agent runtime; we host instances on dedicated tiers tuned for the workload. The storefront is wired, and the hosted deployment layer is the final piece.
  • Mercurial, our self-hosted crypto payments gateway. Already live at mercurial.fi. Replaces an off-the-shelf gateway with one we control end to end — chain monitoring, hot/cold wallet sweeps, deterministic invoice lifecycle, no third-party operator in the critical path. Auto-conversion to stablecoin and configurable mass-send to whitelisted addresses are the next milestones.
  • Phantom, our Web Unlocker tier. Built for proxy customers hitting Cloudflare challenges, DataDome, Akamai BMP, Kasada. Three-stage routing — TLS-fingerprint match, then a headless-browser farm, then captcha solver as the last resort — currently clearing the majority of common anti-bot stacks. A public diagnostic widget lets customers paste a URL and see the classification before they pay.
  • Cross-node backups across plans. Most hosts charge extra for backup features that look more like snapshots than recovery systems. Ours separate live infrastructure from recovery storage by design — different nodes, different storage class, isolated trust boundary. Free across all plans.
  • A new marketing site. V2 is the portal; privatebyte.com still uses the old surface. The marketing front-door rebuild is 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 notes, 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. If anything looks wrong on V2, open a ticket and a real person will reply.