When we started TrueCore, the obvious move was cPanel. It's what everyone uses. It has extensive documentation, customers recognise it, and it handles the core hosting tasks: files, databases, email, SSL. We evaluated it, decided against it, and built our own instead.
Here's why.
The Cost Problem
cPanel licenses on shared hosting typically cost $15–$45 per server per month on a legacy per-server model, or in newer pricing, per account. Either way, those costs get passed to customers as padding built into plan prices. You're paying for cPanel whether you use its features or not.
We wanted to know exactly what we're paying for and charge customers only for what they actually use.
The Complexity Problem
cPanel has evolved for over 25 years. That history shows in the interface — features from 2004 live next to features from 2024, with different design paradigms, varying levels of support, and functionality that assumes an old-school shared hosting model (zone file editors, manual SSL management, raw CGI configuration).
Most customers need: file management, database access, email setup, SSL status, and logs. They don't need Perl module installers, Cron job editors exposed through WHM, or legacy FTP server configuration.
A complex panel creates support requests. Customers get lost, click the wrong thing, and end up somewhere confusing. A simple panel doesn't have those paths.
What We Built
Our customer panel is purpose-built for the workflows our customers actually use. The tabs are:
- Account — your plan, usage, and billing
- DNS — manage your domain's DNS records
- Database — PostgreSQL credentials and connection details (Ember and above)
- SSH — add SSH keys, enable shell access
- Email — add mailboxes, check delivery
- Status — live health check for your site
- Add-ons — one-click installers for WordPress, Adminer, and more
That's it. Every feature in the panel is there because a customer needed it. There's nothing there because it came with a package.
The Technical Result
Because we own the panel code, we can change it quickly. When customers ask for a feature, we can ship it in days, not wait for a cPanel update cycle. When we find a bug, we fix it directly.
We can also integrate deeply with our infrastructure. The panel talks directly to our provisioning system, our DNS server, and our monitoring. A cPanel integration would require adapting to its APIs and working around its assumptions. With our own code, the integration is native.
The site CLI
For customers who prefer the terminal, every panel feature is also available via the site command in their shell: site status, site ssl renew, site logs nginx, site email add. The CLI and the panel share the same backend.
This isn't common in the industry. We think it should be.