Should I use OpenLiteSpeed or LiteSpeed Enterprise with CyberPanel?

OpenLiteSpeed is free, ships with LSCache, and handles WordPress traffic well into the millions of monthly pageviews per site. LiteSpeed Enterprise costs money but unlocks ESI block-level caching, unlimited PHP workers, and full .htaccess parity. For a single agency site I start on OpenLiteSpeed. For a multi-tenant box with WooCommerce and membership plugins doing per-user caching, the Enterprise license pays for itself in load reduction within the first month.

Is CyberPanel safe to put behind Cloudflare?

Yes, with one caveat. The standard proxy mode works out of the box once you set TRUSTED_PROXIES and turn on the real-IP module so visitor IPs aren't logged as Cloudflare's. The caveat is the LiteSpeed admin on port 7080, which Cloudflare won't proxy by default. Keep that port behind your firewall or VPN, never expose it to the public internet, and limit the source IPs that can reach it.

How does CyberPanel compare to cPanel or Plesk?

Different positioning. cPanel and Plesk are commercial control panels with mature ecosystems and per-account licensing fees that scale with the number of accounts. CyberPanel is free at the core and ships with LSCache integration that the others charge for as add-ons. The trade-off is a smaller community, fewer integrations with backup vendors and email security tools, and an admin UI that occasionally lags behind the upstream feature set. For an agency running 5 to 50 WordPress sites on a self-managed VPS, the math leans CyberPanel.

Can I run CyberPanel and Docker on the same box?

Technically yes, practically no. CyberPanel takes ownership of ports 80, 443, 7080, and a handful of others, plus it manages firewall rules through CSF. Layering Docker workloads on top means fighting CyberPanel for the same ports and writing iptables rules around its rules. I keep CyberPanel boxes single-purpose: one VPS for WordPress, a separate VPS for the Docker stack.

How do I move a WordPress site from cPanel to CyberPanel?

The cleanest path is creating the destination website in CyberPanel first, then using a plugin like All-in-One WP Migration or the WP-CLI export/import flow. CyberPanel's built-in remote backup feature can pull from a cPanel backup file, but the import is occasionally fussy with custom MySQL collations. I trust the WP-CLI path more for sites that matter.

CyberPanel: My OpenLiteSpeed Stack for Agency WordPress

I run CyberPanel on the OpenLiteSpeed boxes I use for client WordPress hosting, and after a couple of years of installing it on fresh VPSs I’ve settled on a setup that’s worth writing down. The default install gets you 80% of the way there in 20 minutes. The remaining 20% is the hardening, the cache tuning, and the TLS configuration that the upstream installer leaves to you, and that’s where most CyberPanel deployments either become production-ready or stay as test boxes forever.

This CyberPanel installation guide is the actual sequence I follow when a new server lands in my queue: a clean Ubuntu 22.04 LTS box, the official installer script, then the four post-install changes that make the difference between a control panel I’d hand to a client and one I’d be embarrassed about.

If you’ve never set up CyberPanel before, read the prerequisites section first. The installer assumes a clean OS with no other web server bound to ports 80 or 443, and skipping that check is the most common reason a CyberPanel install fails halfway through.

What CyberPanel actually is

CyberPanel is a Linux hosting control panel for Ubuntu and RHEL-family systems, built on top of the LiteSpeed web server family. The core is open source on GitHub under usmannasir/cyberpanel, and the web server underneath is either OpenLiteSpeed (free, Apache-style config) or LiteSpeed Enterprise (commercial, drop-in Apache replacement with full .htaccess parity).

The pitch is simple: you get LSCache out of the box, which is the most aggressive WordPress caching layer I’ve benchmarked, and you get a control panel that’s pleasant enough for clients to log into without breaking the server. The catch is that the wider ecosystem around CyberPanel is smaller than cPanel’s. Fewer backup vendors integrate with it, fewer email security suites have native plugins, and the admin UI sometimes feels a release behind the underlying engine. None of those are deal-breakers for an agency-scale deployment, but they’re real.

For a typical client setup I run OpenLiteSpeed because it’s free and handles a few million monthly pageviews per site without complaint. I move to LiteSpeed Enterprise on multi-tenant boxes that host WooCommerce or membership plugins, where ESI block-level caching genuinely matters. The licensing model is per-server, not per-account, so the math gets friendly fast on a busy box.

Before you run the installer

The installer is opinionated. It expects to own the box. Treat the prerequisites as non-negotiable.

Server prerequisites

OS: Ubuntu 22.04 LTS, AlmaLinux 9, or Rocky Linux 9. I default to Ubuntu LTS because the package availability is best.
Resources: 2GB RAM minimum for OpenLiteSpeed, 4GB if you plan to run LiteSpeed Enterprise plus a real workload. CPU is rarely the bottleneck; memory and disk I/O are.
Disk: 20GB minimum for the OS and CyberPanel itself. Add separate provisioning for /home if you’re hosting more than a handful of sites.
Network: a clean public IP with reverse DNS configured. Email won’t work without rDNS, and the panel handles outbound notifications.

Hardening the host first

I never run the CyberPanel installer on an unhardened box. The panel adds CSF and a handful of its own firewall rules, but those sit on top of whatever baseline you’ve built. SSH key auth, no root login, fail2ban, and a default-deny firewall are the table stakes. My Linux server security fundamentals post is the exact baseline I run on every new box before I install anything else, and I treat it as the prerequisite for this whole guide.

DNS access is the other thing. Point the box’s hostname A-record at the public IP, and have your client’s domain DNS ready to repoint when you’re ready to migrate.

Running the CyberPanel installer

Once the OS is clean, hardened, and updated, the install is one shell command. The installer is interactive and asks about edition (OpenLiteSpeed or LiteSpeed Enterprise), Redis, Memcached, ModSecurity, and a few other extras.

sh <(curl https://cyberpanel.net/install.sh || wget -O - https://cyberpanel.net/install.sh)

A few notes on the prompts:

Edition: pick option 1 (OpenLiteSpeed) unless you’ve already bought a LiteSpeed Enterprise license and have the serial ready.
Full or Lite: full install. The lite install skips Postfix and OpenDKIM, and you’ll regret it the first time a client wants to send email from their site.
Memcached and Redis: yes to both. Object caching is what makes WordPress feel fast. LSCache handles page caching; Redis handles object caching for the dynamic queries LSCache can’t catch.
Watchdog: yes. It restarts services if they crash and saves you a 3am support ticket.

The installer takes 15 to 30 minutes depending on the box. When it finishes, it prints the admin URL, the temporary admin password, and the panel port (8090 by default). Save those. The temp password should be changed inside the panel within the first minute.

Heads up. The installer does not ask before opening ports 80, 443, 7080, 8090, and a handful of mail ports through CSF. If you have a stricter firewall philosophy, audit the resulting CSF config before exposing the box to clients. The defaults are reasonable for a hosting box but loose for a hardened internal server.

Setting the LiteSpeed admin password

This is the post-install change that catches people out. The LSWS admin interface lives on port 7080, and the default install leaves it without a usable password. Anyone with network access to that port can poke around the admin until they find something to break.

Set a real password before you touch anything else:

sh /usr/local/lsws/admin/misc/admpass.sh

Enter the password twice. Use something long and random, and store it in your password manager. The LSWS admin is where you tune real server-level behaviour: virtual hosts, listeners, SSL contexts, the lot. It’s not a panel meant for clients; it’s a panel meant for operators.

Enforcing TLS 1.3 and turning on the LSCache crawler

These are the two configuration changes I run on every CyberPanel install before I hand the box to a client. Both live in the OpenLiteSpeed httpd.conf, both are one-line edits, and both pay back on every page load.

LSCache crawler

The LSCache crawler is the integration point with the LiteSpeed Cache plugin. It walks the site’s pages on a schedule, fetches each one as a logged-out visitor, and warms the cache before real visitors arrive. The first hit on a sitemap entry is the slow one; the crawler eats the slow hits so your visitors don’t.

Open the OpenLiteSpeed config:

nano /usr/local/lsws/conf/httpd.conf

Find the CacheRoot /home/lscache/ line and add the crawler block underneath:

CacheEngine on crawler
SetEnv CRAWLER_USLEEP 1000
SetEnv CRAWLER_LOAD_LIMIT 5.2

CRAWLER_USLEEP is the microsecond pause between requests. 1000 is gentle. CRAWLER_LOAD_LIMIT tells the crawler to back off if the server load average climbs above 5.2, which on a 4-core box is roughly the threshold where you’d start to feel the lag. Tune both to your server size; the defaults are fine for a 4-core, 8GB box.

TLS 1.3 only

I disable every TLS version below 1.3 on every CyberPanel box I deploy. TLS 1.2 is technically still supported by major browsers, but anything older is a liability and the modern ecosystem has moved on. Enforcing TLS 1.3 only also dodges a couple of older protocol vulnerabilities that you don’t want surfacing in a client compliance audit two years from now.

In the same httpd.conf, find the SSLProtocol line and replace its value:

all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2

Save (CTRL+O, then Enter, then CTRL+X) and restart OpenLiteSpeed:

systemctl restart lsws

Verify the change with openssl s_client -connect yourdomain.com:443 -tls1_2. If TLS 1.2 is genuinely disabled, the handshake should fail. Then run openssl s_client -connect yourdomain.com:443 -tls1_3 and confirm it succeeds. SSL Labs’ SSL Test is the easier way to check; aim for an A or A+ before you call it done.

Useful next steps after the panel is up

Once the panel is up, the password is set, and TLS 1.3 plus the crawler are configured, the box is ready for client sites. A few things I add on top depending on the workload:

CrowdSec in front of the WordPress sites. CyberPanel ships with CSF and ModSecurity, both of which are reasonable, but the modern threat-intel layer is CrowdSec. My CrowdSec installation walk-through covers the bouncer pattern I use, and it sits cleanly alongside CSF without conflict.
Off-host backups. CyberPanel has built-in backup support to local storage, S3, and Google Drive. Local-only backups don’t count, so configure the S3 destination and rotate. I’ve had to restore from off-host backups twice in 6 years; both times the local backups would have been useless because the box itself was the problem.
Uptime Kuma pinging the public URL of every site on the box. CyberPanel can tell you when LiteSpeed is up, but only an external probe can tell you when the actual site is reachable from the public internet. Five-minute interval, with notifications to Slack or Discord.
A separate Docker box for everything that isn’t WordPress. CyberPanel and Docker fight for ports and firewall rules; I keep them on different VPSs. My Portainer + Nginx Proxy Manager + Vaultwarden post covers the companion Docker stack I run alongside a CyberPanel box.

When CyberPanel isn’t the right call

CyberPanel earns its place on a multi-WordPress agency box. There are a couple of cases where I steer clients to a different stack:

Single static marketing site. A control panel adds operational overhead the client will never use. Plain Nginx + WordPress + a FastCGI cache is simpler, lighter, and easier to migrate later. The LSCache benefit doesn’t outweigh the complexity for one site.
Email-heavy hosting. CyberPanel’s Postfix integration is functional but not a replacement for a dedicated email stack. If email deliverability matters to the client, I run Mailcow on a separate box and let CyberPanel handle web only.
Multi-tenant agencies that want server-level account isolation. CyberPanel’s user model is fine for trusted tenants, but the Enhance control panel takes container-level isolation more seriously, and that matters when one tenant’s compromised plugin can’t touch another tenant’s filesystem.

If none of those exceptions apply, CyberPanel is the right tool. The installer is fast, the hardening I’ve covered above is a one-time cost, and the resulting box is something a client can log into without breaking.

Closing the loop

A CyberPanel install I’d hand to a client takes about an hour from a fresh server: 30 minutes for the host hardening baseline, 20 minutes for the installer, 10 minutes for the LSWS admin password, TLS enforcement, and crawler config. After that, the panel mostly stays out of your way and lets you focus on the WordPress sites it’s hosting.

The mistake I see most often with CyberPanel boxes is treating the installer as the finish line. The installer gets you a control panel; the four post-install changes in this guide are what make it production-ready. Run them in order on every new box, document the admin password somewhere your future self can find it, and the box will quietly serve client sites for years.