The API Guys
A server rack with a broken chain symbolising freedom from cPanel and WHM
·5 min read·The API Guys

Why We Dropped WHM and cPanel

Server ManagementLaravel ForgecPanelDevOpsInfrastructure

For years, cPanel and WHM were the default choice for managing web servers. They offered a familiar interface, handled the basics, and gave clients a way to poke around their hosting without needing to call us. But over time, what once felt like a convenience started to feel like a burden.

This is the story of why we walked away from cPanel and WHM, and why we haven't looked back since.

The Licence Cost Problem

Let's start with the elephant in the room. When cPanel was acquired by Oakley Capital in 2018, the licensing model changed dramatically. What had been a flat, predictable monthly fee suddenly became an account-based pricing structure that scaled with the number of accounts on a server.

For agencies and developers managing multiple client sites across several servers, this was a significant hit. We watched our hosting costs climb without any corresponding improvement in the product. The value proposition simply stopped making sense. We were paying more for software that, frankly, we were using less and less of.

Bloat We Didn't Need

cPanel is designed to be everything to everyone. Email management, DNS configuration, file managers, database tools, one-click installers, security scanners - the list goes on. On paper, that sounds comprehensive. In practice, it meant we were running a heavyweight control panel packed with features we never touched.

Every one of those features consumes server resources. Every one of them represents a potential attack surface. And every one of them needs updating and maintaining. When you're running modern Laravel applications behind Nginx with Redis caching and queue workers, most of what cPanel offers is completely irrelevant.

We found ourselves working around cPanel more than we were working with it. Custom Nginx configurations were awkward to manage. PHP version management felt clunky. The Apache-centric defaults didn't align with how we build and deploy applications.

Security Concerns

Any software that sits on your server is a potential vulnerability, and control panels are particularly attractive targets. cPanel has had its share of security issues over the years, and running such a large, complex piece of software on production servers always felt like an unnecessary risk.

The more software you run, the more you need to patch. The more you need to patch, the more things can go wrong. We wanted to reduce our attack surface, not expand it.

The Shift to Direct Server Management

The turning point came when we started using Laravel Forge. For those unfamiliar, Forge is a server management tool built specifically for PHP developers. It provisions and manages servers on providers like DigitalOcean, AWS, Hetzner, and others, configuring them with a modern stack out of the box.

With Forge, we get exactly what we need and nothing we don't. Nginx, PHP (any version we want, switchable per site), MySQL or PostgreSQL, Redis, SSL certificates via Let's Encrypt, queue workers, scheduled tasks, and deployment scripts. Everything is configured for modern PHP applications from the start.

What We Gained

The benefits became apparent almost immediately:

Lower costs. A Forge subscription costs a fraction of what we were paying in cPanel licences. The servers themselves are cheaper too, because we're not wasting resources running a control panel.

Better performance. Without cPanel's overhead, our servers run leaner. Nginx handles requests more efficiently than Apache for our use cases, and we have full control over PHP-FPM pool configurations.

Tighter security. Fewer running services means fewer vulnerabilities. We control exactly what's installed and running on each server. Forge handles security updates and firewall rules, and we can lock things down exactly how we want.

Modern workflow. Deployments happen via Git. Push to main, and Forge pulls the latest code, runs migrations, clears caches, and restarts queue workers. No FTP, no file managers, no messing about.

Full control. We have root SSH access and complete control over our server configuration. If we need to tweak an Nginx config, install a specific package, or set up a custom cron job, we just do it. No fighting with a control panel that thinks it knows better.

But What About Clients?

One of the common arguments for cPanel is that it gives clients access to manage their own hosting. In our experience, most clients never actually use it. Those who do are usually better served by purpose-built tools anyway. Email? Use Google Workspace or Microsoft 365. DNS? Manage it through Cloudflare. Databases? We handle those as part of our development workflow.

Removing cPanel from the equation didn't create any gaps in our client service. If anything, it improved things because our infrastructure became more reliable and easier to maintain.

Is cPanel Dead?

Not at all. cPanel still has its place, particularly for shared hosting providers and environments where non-technical users need direct server access. But for professional development teams building and deploying modern applications, it's increasingly hard to justify.

If you're a Laravel developer still running cPanel, we'd genuinely encourage you to look at Forge. The learning curve is minimal, and the improvement in your workflow, costs, and server performance is substantial.

Our Stack Today

For the curious, here's what our typical server setup looks like now: Ubuntu LTS on DigitalOcean or Hetzner, provisioned and managed through Laravel Forge. Nginx serves our applications, with PHP 8.3, MySQL 8 or PostgreSQL, Redis for caching and queues, and SSL certificates handled automatically by Let's Encrypt. Deployments are triggered by Git pushes, and monitoring is handled through Forge's built-in tools alongside external uptime checks.

It's clean, it's fast, and it's entirely under our control. And that's exactly how we like it.

Ready to Start Your Project?

Get in touch with our Leeds-based team to discuss your Laravel or API development needs.