DEV Community: Shuki Vaknin (‫אחסון לינוקס‬‎)

An open-source cPanel alternative for Debian 13

Shuki Vaknin (‫אחסון לינוקס‬‎) — Sun, 26 Jul 2026 20:01:40 +0000

Originally published at jabali-panel.com.

If you run a Debian server and you are tired of paying per-account fees for a hosting control panel, this post is for you. Jabali Panel is a GPL-licensed control panel built for one operating system — Debian 13 (Trixie) — and one job: managing hosted websites, email, and DNS for end-user accounts.

Why we built another panel

Most existing panels fall into one of two camps. The commercial ones (cPanel, Plesk, DirectAdmin) charge per account and lock features behind tiers. The free ones (HestiaCP, CyberPanel, aaPanel) make different trade-offs around language, security model, or maintenance cadence. We wanted something Debian-native, AGPL-licensed end to end, and built on a modern Go + React stack rather than a PHP monolith.

The stack

The panel API is jabali-panel-api, a Go service using Gin for HTTP routing and GORM for the data layer. The browser UI is a React single-page application built on Ant Design and TanStack Query. Privileged host operations — anything that needs root — run in a separate process, jabali-agent, accessed over a Unix domain socket. The panel itself does not run as root.

PHP, in this stack, is a hosted workload: each user gets their own PHP-FPM pool, and the panel manages versions 8.1 through 8.5 from the Sury repository per domain. The panel is not written in PHP.

What you get on a fresh install

Run the installer on a clean Debian 13 host and 8–15 minutes later you have:

nginx as the reverse proxy and TLS terminator
MariaDB 11.x for tenant databases (PostgreSQL is opt-in)
PowerDNS Authoritative for hosted zones, pdns-recursor for panel-internal resolution
Stalwart Mail 0.16.0 — SMTP, IMAP, JMAP in a single binary — with Roundcube webmail
certbot issuing Let's Encrypt certificates per domain
CrowdSec AppSec WAF inline with nginx, plus Snuffleupagus, AppArmor, AIDE, and auditd
PowerDNS DNSSEC signing per domain (opt-in), with the DS record surfaced in the UI for registrar publication
WP-CLI 2.12.0 powering one-click WordPress installs with a self-deleting SSO link into wp-admin

Everything is provisioned automatically. Nothing requires manual operator install.

Migrating from cPanel

The Migrations section accepts cPanel .tar.gz and cpmove archives directly. It also reads DirectAdmin, Hestia, and WHM backups. The restore is per-account, tracked in the UI, and writes domains, databases, mailboxes, DNS zones, and cron jobs into the new layout.

A few cPanel-specific notes:

MySQL passwords are bcrypt in cPanel ≥ 11.96. Jabali stores the bcrypt hash directly in MariaDB so migrated apps keep authenticating without password reset.
Email accounts move from cPanel's Dovecot+Exim to Stalwart. Mailbox passwords cannot be migrated as-is — the migration report prints the new passwords, or you can flip the "force first-login password reset" option.
DKIM keys are imported as-is so outbound deliverability survives the switch.

What you don't get

A few honest caveats:

This is single-host. There is no clustering. One panel, one VPS.
We support Debian 13 only. The installer exits on earlier Debian releases or Ubuntu — not because we dislike Ubuntu, but because supporting a single distribution lets us actually test what we ship.
The panel itself is English-only in the UI today. End-user features (webmail, autoconfig profiles) honour the user's browser locale.
We sell paid support and pre-configured VPS instances. The software itself stays free; nothing is gated behind a paid tier.

Try it

curl -fsSL https://jabali-panel.com/install.sh | bash

That's the whole install command. The script is idempotent and safe to re-run. From a clean Debian 13 VPS, expect 8–15 minutes to a working panel at https://<panel-hostname>/.

If you'd rather see it first, the demo panel runs the live UI with seeded admin and user accounts. Everything is read-only — useful for clicking around without spinning up a server.

For longer-form documentation, the installation guide and quickstart walk through DNS prep, panel-hostname certificate issuance, and creating your first hosted user.

How to Preview a Website on a New Server Before You Change DNS

Shuki Vaknin (‫אחסון לינוקס‬‎) — Sun, 26 Jul 2026 19:54:14 +0000

Every website migration has the same terrifying moment: you flip the DNS record, and for the next few hours you have no idea whether the new server is actually serving your site correctly — or quietly 500-ing for half the planet while it propagates.

The fix is simple: test the new server before you change DNS. Here's how to do that properly, plus the checks I run on every migration so nothing breaks silently.

The old way: editing your hosts file

The classic trick is to point your machine at the new server by adding a line to your local hosts file:

203.0.113.10   example.com

This works, but it's painful: you edit a system file with admin rights on every device, your phone and your client's laptop can't easily see it, and you will forget to remove the line and then debug "why is the site broken on my machine only."

The faster way: a temporary preview URL

Instead of editing the hosts file, you can generate a temporary URL that resolves to the new server's IP for your chosen domain — no local changes, works on any device.

I built a free tool for exactly this: hosts.click ("The Website Previewer"). You give it the new server's IP and the domain, and it hands you a temporary preview URL. Open it anywhere — desktop, phone, share it with the client — and click through the whole site exactly as it will look once DNS points to the new host. No hosts file, no DNS change, no waiting for propagation.

Diff the old and new server before you cut over

The most dangerous migration bugs are the silent ones — a redirect that changed, a header that got dropped, a page that's subtly different. Eyeballing every page won't catch them.

Run a server diff: hit the same paths on the old IP and the new IP and compare status codes, redirect chains, response headers, response time, and a hash of the page body. If the body hash differs on a page you didn't touch, find it now, not after the cutover.

Free tool: server diff — old IP vs. new IP, side by side.

Don't lose email

They change the domain's A record and their email stops working, because they assumed "changing hosts" meant changing everything. It doesn't. Your website (A/AAAA record) and your email (MX records) are independent. If you're only moving the website, leave the MX records alone. Verify your mail DNS — MX, plus SPF, DKIM, and DMARC — with an email DNS checker so you don't quietly drop into spam folders.

Lower your TTL first

DNS propagation isn't magic; it's caching. Every DNS record has a TTL (time to live). If your A record has a 24-hour TTL, your cutover can take 24 hours to fully roll out. At least a day before you migrate, drop the TTL on the records you'll change to 300 seconds. Then when you flip the record, the switch propagates in minutes instead of hours.

Watch the cutover propagate

Once you change the record, you want to see it roll out across the world rather than guessing. Query the domain against many public resolvers and watch them converge on the new IP.

Free tool: DNS propagation checker — compares your record across 45 public resolvers worldwide on a map.

Re-check the boring stuff on the new host

New server, new defaults. Confirm the new host matches the old one on what doesn't show visually:

Caching & compression — sensible Cache-Control and gzip/Brotli? Check the cache checker.
HTTPS & the cert chain — valid, covers the hostname, complete intermediates? Run an SSL checker.
Security headers — HSTS, CSP, X-Content-Type-Options.
Redirects — did your http → https and www canonicalization survive the move?

The short version

Test before you switch, switch fast, verify after:

Preview the site on the new server before touching DNS.
Diff old vs. new to catch silent changes.
Leave MX alone unless you're moving email too.
Lower TTL 24h ahead.
Flip DNS, watch it propagate.
Re-check cache, SSL, security headers, redirects.

All the tools for each step are free (no signup) at hostsclick.com/tools. For a version tailored to your specific hosts, the migration checklist generator builds one for you.

Migrate boldly. Just test first.

LiteSpeed vs Nginx for WordPress: 3 months of production benchmarks

Shuki Vaknin (‫אחסון לינוקס‬‎) — Sun, 26 Jul 2026 01:42:28 +0000

TL;DR

Ran LiteSpeed Enterprise (LSWS) and Nginx side-by-side on identical VPS instances for 3 months, hosting the same 12 WordPress sites on each. LiteSpeed came out 33–45% faster on TTFB and moved 10/12 sites to a 90+ mobile PageSpeed score vs. 3/12 on Nginx. But ~80% of that advantage doesn't come from LSWS itself — it comes from the LSCache plugin, which also works with OpenLiteSpeed (free).

If you're deciding today: OpenLiteSpeed + LSCache is the pragmatic answer for most WordPress workloads.

The setup

Two identical VPS instances at the same Israeli data center:

Server A: LiteSpeed Enterprise 6.2 + LSCache 5.7 + PHP 8.2 (LSAPI) + CloudLinux
Server B: Nginx 1.24 + PHP 8.2 FPM + FastCGI cache + Redis object cache

Spec on each: 4 vCPU, 8 GB RAM, 100 GB NVMe, Ubuntu 22.04.

12 WordPress sites migrated to each (same versions, same plugin stack):

4 brochure sites (~50 pages, empty WooCommerce)
4 WooCommerce stores (500–2000 products)
4 Elementor blogs (500+ posts)

Load simulated with k6, 100 concurrent users, 30-min runs, realistic paths: home → category → product → cart → checkout.

Results — TTFB

Site type	Nginx	LiteSpeed	Δ
Brochure	142 ms	89 ms	−37%
WooCommerce empty	168 ms	112 ms	−33%
WooCommerce full	384 ms	210 ms	−45%
Blog	156 ms	98 ms	−37%

Results — RPS under load

Site type	Nginx	LiteSpeed	Δ
Brochure	340	520	+53%
WooCommerce empty	210	340	+62%
WooCommerce full	62	118	+90%
Blog	280	470	+68%

The gap widens with deeper PHP call trees. WooCommerce with a big catalog is nearly 2× faster on LSWS. Reason: LSAPI keeps a persistent worker pool that avoids PHP-FPM's cold-start overhead on complex requests.

Results — PageSpeed Insights (mobile)

Averages across all 12 sites, both stacks with the same image + Critical-CSS pipeline:

Metric	Nginx	LiteSpeed
LCP	2.4 s	1.6 s
FCP	1.7 s	1.1 s
CLS	0.03	0.03
TBT	240 ms	190 ms
Score	84	94

LiteSpeed moved 10/12 sites to 90+. Nginx got 3/12 there.

The plot twist

Three months in, I did one more test: installed OpenLiteSpeed (free, MIT license) + LSCache on Server B, in place of Nginx. Same 12 sites.

Metric	Nginx + FastCGI + Redis	OpenLiteSpeed + LSCache
TTFB (WooCommerce full)	384 ms	245 ms
PageSpeed (mobile)	84	92
License cost	$0	$0

~80% of LiteSpeed Enterprise's advantage came from the cache plugin, not the server. LSCache does four things no other WordPress cache plugin does at the same level:

QUIC.cloud CDN, free tier (built into the plugin)
Image optimization + WebP conversion in-process
Automatic Critical CSS generation
ESI edge-side includes — cache the shell of a page while keeping dynamic bits fresh (mini-carts, logged-in nav)

Recommended config

wp-config.php:

define('WP_CACHE', true);
define('WP_DEBUG', false);
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_DATABASE', 0);
define('WP_POST_REVISIONS', 5);
define('AUTOSAVE_INTERVAL', 300);

Critical LSCache settings (Dashboard → LiteSpeed Cache):

Cache → General → Enable Cache: On
Cache → General → Cache Logged-in Users: Off (important)
Cache → Object → Object Cache: Redis
Cache → ESI → Enable ESI: On
CDN → QUIC.cloud CDN: On
Page Optimization → CSS: Combine + Minify + UCSS
Page Optimization → JS: Combine + Defer
Page Optimization → Images: Guest Optimization + Lazy Load
Page Optimization → HTML: Minify + DNS Prefetch

When Nginx still wins

API-only WordPress backends (headless) — Nginx + FPM has a tighter footprint for pure JSON responses.
Truly static traffic — landing pages, marketing sites with no dynamic content. Nginx + static file cache is unbeatable there.
Team that only knows Nginx — LSWS/OLS learning curve isn't worth it for a single box.

Eight-point WordPress performance checklist

curl -o /dev/null -s -w "%{time_starttransfer}\n" https://yoursite.com/ → TTFB under 200 ms
PageSpeed Insights on home + 3 product pages → LCP under 2.5 s
GTmetrix waterfall → cache HIT on every static asset
X-LiteSpeed-Cache: hit header on repeat requests (or equivalent for your cache)
Search Console → Core Web Vitals → 90%+ URLs "Good"
wp cli plugin list --status=active → under 25 active plugins
wp-admin → Site Health → no "Critical" issues
Redis object cache active — check "Cache Statistics" in your cache plugin

Bottom line

For WordPress in 2026:

On a shared host: LiteSpeed Enterprise + LSCache is the strongest option. Pay the license, forget about tuning.
On your own VPS: OpenLiteSpeed + LSCache gets you 90% of the way there for free.
Nginx: still the right call for API-only or ultra-static workloads, or if your team lives and breathes it.

Two days of proper LSCache config usually beats switching hosts.

I run Linux Hosting, an Israeli hosting provider running LiteSpeed Enterprise + LSCache across every plan. Comments and pushback welcome — this was measured on a real customer fleet, but every setup is different and I'd love to see other benchmarks.