CyberPanel and CloudPanel alternative: one AGPL hosting panel with a migration path from both

Two of the most active open-source hosting panels — CyberPanel and CloudPanel — each solve a different slice of the hosting problem and each impose a different kind of lock-in. CyberPanel bets on OpenLiteSpeed; CloudPanel skips mail entirely. Both are fine choices, but growth exposes the ceiling.

This post explains the case for consolidating both onto one AGPL-licenced panel, and walks through the SSH-pull migration pipelines Jabali Panel ships for each.

Two different lock-ins

CyberPanel’s lock-in is the web server. OpenLiteSpeed is fast and its LSCache extension is great for WordPress — but it’s a stack choice that touches every site config, .htaccess handling, and cache layer. Moving off OLS means re-testing every site’s rewrite rules. And CyberPanel’s Enterprise tier gates the features most production shops actually reach for (Docker at scale, SLA, remote backups) behind a licence bill.

CloudPanel’s lock-in is the scope. The panel is deliberately web-only: no mail server, no DNS-authoritative option, no first-class Docker. That’s a virtue for shops that only host static sites + PHP apps and outsource mail. But if you ever want to consolidate mail hosting — or run a Nextcloud instance next to a WordPress site — you’re stuck. The migration path is “install a second panel”, not “add a feature”.

Jabali Panel is the both/and. AGPL, nginx + PHP-FPM (no proprietary web server), Stalwart for mail, PowerDNS for DNS, a 64-app Docker marketplace. And the CyberPanel + CloudPanel migration pipelines are built in.

Same platform surface, no lock-in

Feature	CyberPanel	CloudPanel	Jabali Panel
Licence	Open-core	MIT	AGPL
Web server	OpenLiteSpeed	nginx	nginx + PHP-FPM
Mail	Postfix + Dovecot	—	Stalwart (SMTP/IMAP/JMAP)
DNS	PowerDNS	—	PowerDNS
Databases	MariaDB	MariaDB	MariaDB + PostgreSQL
WP Toolkit	LSCache	FastCGI cache	Jabali Cache
Docker apps	Limited	—	64+ curated stacks
WAF	ModSecurity	Cloudflare-only	AppSec + CrowdSec
Node.js	Add-on	First-class	First-class
Migration in	cPanel only	cPanel only	cPanel + DirectAdmin + HestiaCP + Plesk + CyberPanel + CloudPanel + WHM + IMAP

How the SSH-pull migrations work

Neither migration needs an archive produced on the source. Both work by SSHing in and reading the source’s config database directly:

CyberPanel keeps its entire inventory in a MySQL database called cyberpanel. From internal/migrate/cyberpanel/discover.go:

CyberPanel keeps its whole inventory in the cyberpanel MySQL database. Enumeration is plain read-only SELECTs via the mysql CLI over SSH (the SSH user is root; CyberPanel’s mysqld grants root passwordless local access). We NEVER run a mutating statement against the source.

Concretely: websiteFunctions_websites for site metadata, databases_databases for MySQL databases, e_users for mailboxes, e_forwardings for mail forwarders, e_domains for mail-domain-to-website mapping, packages_package for hosting packages.

CloudPanel keeps its inventory in SQLite. From internal/migrate/cloudpanel/discover.go:

CloudPanel stores its entire inventory in a single SQLite database at /home/clp/htdocs/app/data/db.sq3 (tables: site, php_settings, database, user). Enumeration is therefore plain read-only SELECTs via the sqlite3 CLI over SSH.

clpctl is used only for DB credentials + mysqldump. Never mutating.

Both pipelines share the read-only contract: no create, no delete, no modify against the source. Discovery days ahead is fine — the source stays operational.

Walk-through: CyberPanel migration

1. Register the source in /jabali-admin/migrations — kind cyberpanel, host, SSH port, root credentials.
2. Discover — SELECT domain FROM websiteFunctions_websites runs; site list appears.
3. Select sites — pick one, several, or all. Assign a target Hosting Package.
4. Analyze — pipeline reads websites, databases, mailboxes, forwarders, cron. Report shows exactly what will land.
5. Restore — files streamed over SSH, mysqldump produces DB content, DNS zones translated to PowerDNS, mailboxes rebuilt in Stalwart with generated passwords.
6. Communicate mail passwords to users (Dovecot hashes don’t port to Argon2id).
7. Repoint DNS.
8. Issue SSL — certbot HTTP-01 via the per-domain toggle.

Full technical reference: CyberPanel migration docs.

Walk-through: CloudPanel migration

1. Register the source — kind cloudpanel.
2. Discover — sqlite3 /home/clp/htdocs/app/data/db.sq3 "SELECT domain_name FROM site" runs.
3. Select sites.
4. Analyze — pipeline reads site config, php_settings, databases, site users.
5. Restore — no mail phase. Node.js / Python / Static sites all translate.
6. Repoint DNS.
7. Issue SSL.

Full technical reference: CloudPanel migration docs.

What breaks (and what to do)

CyberPanel: OpenLiteSpeed to nginx. Straightforward .htaccess mod_rewrite rules translate; LSAPI-specific directives don’t. Review each site’s .htaccess after Restore. LSCache is replaced by Jabali Cache for WordPress — object cache + full-page cache wired to Redis, no configuration.

CyberPanel: mailbox passwords are not portable. Dovecot’s hash format doesn’t port to Stalwart’s Argon2id store. Generated passwords land in the migration report. Deliver out of band or set force-first-login reset in Server Settings. Mailbox contents (INBOX + folders + flags) migrate intact via IMAP.

CloudPanel: no mail to consolidate. The source has no mailboxes. If you want first-class mail hosting after the migration, provision mailboxes on the destination in Stalwart, MX-repoint the domain at the registrar, and use IMAP move to copy content from your external provider. See self-hosted mail server for the full walkthrough.

Both: WAF rules don’t translate. CyberPanel ModSecurity rules and CloudPanel’s Cloudflare-only WAF are replaced by AppSec + CrowdSec at the server level — no per-site config.

Both: Docker features don’t translate 1:1. Reinstall from the Jabali Docker marketplace for the same one-click experience with harder tenant isolation.

Try it before you cut over

The Analyze step of both pipelines is strictly read-only. You can point Jabali Panel at a live CyberPanel or CloudPanel host, run Analyze, and review the report without touching production DNS or the source. Verify what would be migrated, spot-check a database restore on the destination, then decide whether to run Restore.

Full docs:

• CyberPanel migration →
• CloudPanel migration →
• Plesk migration — same SSH-pull model, plesk bin-based
• Migration overview — every supported source, the four-phase pipeline