M
Muhammad Bilal
Guest
"Access denied."
Two words in the terminal, and my hosting panel stopped dead.
I had asked FrankenPHP, the web server running the panel, to do something every control panel on earth does a hundred times a day. Restart a service. It refused. I asked it to read a service log from the systemd journal, and it refused that too. I tried writing a
Every engineer who has fought SELinux knows the instinct that came next. Find the switch. Turn it off. Move on.
I didn't.
The longer I stared at those denials, the clearer it became that nothing was broken.
The problem was mine. I was trying to build a hosting panel through the leash.
That single moment decided the architecture of JinnPanel, the free, open-source WHM/cPanel-style control panel I have just released as a public beta. Everything else in this article grew out of it.
I have spent fourteen years shipping software, more than twenty products of it, and a surprising amount of that work has ended up living on a server with a control panel licence attached to it. The panel is the part nobody brags about. It is also the part that sends an invoice every single month.
cPanel & WHM starts at roughly $27 a month per server [2]. Real per-account isolation on top of it usually means CloudLinux, which is another line on the bill. Running a small hosting business this way is like renting the keys to your own house, monthly, from someone who has never lived in it.
So I built my own house.
JinnPanel manages a single AlmaLinux 10 server end to end: resellers, hosting accounts, domains, email, DNS, databases, SFTP, backups, and one-click migration out of cPanel. It is MIT licensed. No per-account fees, no closed modules, no "premium edition" hiding the feature you actually need.
The stack is small and deliberately modern. FrankenPHP (built on Caddy) sits at the front. PHP-FPM runs customer code. MariaDB holds the data, Stalwart handles mail, Knot DNS answers queries, SFTPGo moves files, and Valkey caches objects. The panel itself is plain PHP and Tailwind. No framework. No Composer.
That last choice is not nostalgia. A hosting panel runs as close to root as software gets, and I wanted anyone who installs it to be able to open the code that is running their server and actually read it.
One script installs the whole thing on a fresh box. No prompts. Every internal credential is generated randomly, and no admin password is ever baked into the installer or the repository.
Back to those two words. Once I accepted that the web server should never do privileged work, the question became simple. Who does it instead?
The answer is a small PHP script called the root worker. A systemd timer runs it every five seconds, as root, spawned by PID 1, completely outside FrankenPHP's process tree. The web app never restarts anything, never touches
Think of a bank teller behind thick glass. You slide a signed form under the window. The teller checks the signature, checks that the form is one they recognise, and only then walks to the vault. The vault never opens to the lobby.
That glass matters, because the queue folder is writable by the web server, and anything the web server can write, an attacker who compromises it can write too. So the worker trusts job files as little as possible. Every job is signed with an HMAC key derived from the app's secret. It must be a regular file owned by the web server user or root, never a symlink. Settings jobs accept only a fixed list of keys, each with its own expected value shape. Account jobs carry nothing but an ID, and the worker reads everything else from the database itself.
Every "Save & restart" button in the panel goes through this queue. So does every DNS zone, every new account, every domain change.
The same worker solves the read side of the problem. FrankenPHP cannot read the systemd journal, so on every cycle the worker snapshots the last 200 lines of each service's log into a root-owned folder, and the admin dashboard simply reads a plain file.
There was one more wall, and this one was stranger. Forking a child process from FrankenPHP and having that child connect to a Unix domain socket failed with
It is why Knot DNS's
Long-running work follows the same rule, one step further. A cPanel migration can take hours for a single account, so it runs as its own transient systemd unit. Not as root, because everything it unpacks came from somebody else's server. Not as a child of the web server, because no web request should live for hours.
The rule is simple. Privileged or long work never happens inside a request.
Shared hosting is a building full of tenants who have never met and never should. One badly patched WordPress plugin in apartment 4B must not be able to walk into 7A and read the database password sitting in
Most panels solve this with a paid kernel layer. JinnPanel solves it with the oldest security boundary Linux has. Users.
Every hosting account is its own Linux user,
The part I am proudest of is the one nobody sees. Caddy never serves a customer's file contents. Not one byte. Every non-PHP request is handed to that account's own static file server, an nginx instance running as the account's Linux user, configured to refuse symlinks pointing at files the account doesn't own. If a customer plants a link to a neighbour's files, or to the panel's own config, nginx reads it with that customer's rights. It gets nothing.
Caddy is the concierge in the lobby. It knows which doors exist. It holds none of the keys.
The panel lives by the same rule. When a customer uses the File Manager, unzips an archive or clears OPcache, the panel does not reach into their folder with elevated rights. It sends a FastCGI request into the customer's own PHP pool, to a small agent that refuses anything a normal web request could carry. Files it creates belong to the customer, because the customer's own user created them.
Small details close the gaps between the big ones. The customer panel is served on every domain at port 2083, and since cookies are not scoped by port, the site blocks strip the panel's session cookie before a request ever reaches the customer's PHP. Caddy's admin API sits on a Unix socket, because on
No CloudLinux. No licence. Just users, pools and sockets, used the way they were designed to be used.
Anyone who has run a mail server knows the old stack. Postfix for SMTP, Dovecot for IMAP, OpenDKIM for signing, Rspamd for spam, and a pile of flat config files holding them together like duct tape on a water pipe. It works. Until it doesn't, and then you spend a weekend reading headers.
JinnPanel uses Stalwart instead, a single Rust binary that does all four jobs and exposes a structured management API rather than text files [1]. The panel drives it over JMAP on loopback.
Every mail domain gets SPF, DKIM in both RSA and Ed25519, DMARC, MTA-STS, autoconfig and autodiscover, published automatically. Nobody has to remember to add the DMARC record. A daily timer re-syncs the records, copies the web server's certificate to Stalwart and keeps the submission port alive. Webmail comes included.
Stalwart also gave me a gift I didn't expect. Its settings are described by a live schema, so the panel's mail configuration screens are generated from that schema instead of hand-built. The admin sees 27 settings objects today. Adding another is one line of code, not one more form.
DNS follows the same philosophy. The panel's database is the single source of truth, and zone files are rendered from it. Every change bumps the serial and goes through the root worker, which writes the zone, asks Knot to reload it, and restores the previous file if Knot rejects the new one. A bad record never takes a domain offline.
HTTPS has no custom code at all. Caddy's automatic HTTPS engine is mature, so the panel simply hands it the domain. The moment a domain points at the server with ports 80 and 443 reachable, Let's Encrypt issues the certificate. There is no button to press.
And suspension actually suspends. Sites return 503, PHP pools stop, mail logins are refused, SFTP is disabled, MySQL users are locked, the cache login is switched off, cron jobs are skipped and panel sessions end. One click, everywhere at once. Unsuspending reverses every step.
A free panel that nobody can move into is a museum piece. The real lock-in in hosting has never been the licence. It is the fear of the move.
So migration is built in, and it is free. JinnPanel can pull accounts from a live cPanel/WHM server, as a single account, as a reseller, or as an entire server through WHM root. It can also restore from cPanel backup files or from S3.
What comes across is the whole life of an account, not just its files. Sites, databases, mailboxes along with the mail already stored in them, DNS records, cron jobs, forwarders, autoresponders. Even
Under the hood, the panel only validates the request and records it. The root worker launches a separate migration runner that asks the source server for a full backup, receives it either by download or through a single-use SFTP user, then restores it through the exact same services the panel uses for everything else. Every name and path inside the backup is validated before it touches the disk. A heartbeat notices if the runner dies, and a half-restored account rolls back cleanly. The source server's credentials are encrypted with AES-256-GCM and wiped the moment they are no longer needed.
Now the honest part. The backup-file path has been proven on a real cPanel server's archives. The live API transfer has not yet been run against a real cPanel server [2]. If you have one to spare and want to break it, I would genuinely like to hear what happens.
Claims are cheap. Installers are not. So I went back to the one file that cannot exaggerate,
FrankenPHP, built on Caddy, answers every web request and terminates TLS. PHP-FPM runs customer code, one pool per account per PHP version, with 8.5 as the default and 8.2, 8.3 and 8.4 installable beside it. nginx runs once per account to serve that account's static files. MariaDB holds the panel's state and every customer database. Stalwart handles all mail, SFTPGo handles file transfer, Knot DNS answers queries, and Valkey provides the object cache, with one locked-down login per account. Cypht serves webmail, phpMyAdmin sits behind single sign-on, and firewalld with fail2ban guards the doors. The installer also opens UDP 443, so HTTP/3 is on from the first boot [15].
Here is that stack set beside what the established panels ship.
Sources: JinnPanel's installer [15]; other panels from the vendor pages collected in JinnPanel's comparison, checked 1 October 2026 [3], and cPanel's PHP handler documentation [10].
Read the mail row twice. Every other panel runs two or three daemons stitched together for mail. JinnPanel runs one. That is the whole philosophy of the stack in a single cell: fewer moving parts, each one managed through an API instead of a pile of config files.
A comparison table that only lists wins is an advertisement. This one keeps the red marks, mine included. Every JinnPanel cell comes from its feature reference, which is written from the code [14]; every other cell comes from a vendor page or a cited source.
built in · 
partly, paid or with conditions · 
no · ? not confirmed from an official source (it does not mean no)
Sources: JinnPanel [14] [15]; other panels per JinnPanel's comparison, checked 1 October 2026 [3], with the mail rows re-checked for this article: cPanel does not create DMARC [16], Plesk's DNS template includes a p=none DMARC record [17], DirectAdmin creates DKIM when it is enabled server-wide [18] and leaves DMARC to a custom DNS template [19], and HestiaCP's documented records include DMARC at p=quarantine [20]. SELinux: cPanel [13], JinnPanel [1] [15].
Count the marks in my own column. Seven, plus a warning sign on the operating system. No CPU or RAM containment, no incremental backups, no DNS clustering, no plain FTP, no app installer, no billing API, no paid support, and only AlmaLinux 10. Those are not footnotes. They are the reasons a hosting company with ten thousand customers should not move tomorrow.
Now look at what sits on the other side of the ledger. Most of it never fits in a checkbox, so here it is in plain words, each item taken from the code [14].
Suspension in JinnPanel is not a flag on a website. One click stops the account's sites with a 503, stops its PHP pools, refuses its mailbox logins while still accepting its incoming mail, disables its SFTP logins, locks every MySQL login and kills open connections, disables its Valkey login, skips its cron jobs and signs it out of the panel. Eight services, one switch, every step reversed on unsuspend.
Mail DNS is done for you down to the details most panels skip. Beyond SPF, DKIM and DMARC, every mail domain gets MTA-STS, TLS reporting, SRV records and autoconfig/autodiscover, so a phone or a desktop mail app sets itself up from an email address alone. Your own SPF or DMARC record always wins over the panel's.
The web server does not read
An exposed-files scanner walks each document root for things anyone could download: archives, database dumps, backup copies, logs, customer exports. One button moves them outside the web folder. Dotfiles like
Caching comes in three layers per domain: a compressed static file cache, a page cache for anonymous visitors, and a Valkey object cache whose login cannot run
For the admin, the Stalwart settings screens are generated from the mail server's own schema, 27 settings objects with no hand-built forms. A Server Tweaks page reads the machine's cores, memory and disk and offers Balanced, Performance and Extreme profiles for MariaDB, PHP, OPcache, Stalwart and SFTPGo, showing the exact values before applying them. Live logs for every service sit on the dashboard, and every sign-in and every change lands in a searchable activity log with the source IP.
None of these make JinnPanel bigger than cPanel. They make it sharper in the places where small hosting operators actually bleed.
HackerNoon readers check numbers, so let me be exact about these. Nobody has load-tested JinnPanel end to end yet, me included. What does exist is a body of independent, published benchmarks for the parts it is built from. Read what follows as a dyno sheet for the engine. It is not a lap time for the car.
The engine still matters. Every hosting panel is a bet on a stack. cPanel ships Apache through EasyApache 4 for the web, Exim and Dovecot for mail, and PowerDNS for DNS with BIND as an option. Plesk and HestiaCP lean on Apache, NGINX and BIND. CyberPanel is built on OpenLiteSpeed [3]. JinnPanel bets on Caddy, nginx, Stalwart and Knot.
Start with the front door. In 2025, LinuxConfig.org benchmarked six web servers on identical Debian 12 virtual machines, every one left on its default configuration, then held each under 500 concurrent connections for a full minute [4].
Under light load, the gap vanishes. Serving one small HTML page to 100 concurrent users, Apache managed 7,508 requests per second and Caddy 7,532 [4]. A rounding error. The difference only opens as connections pile up, which is exactly what a shared server looks like when many of its sites get busy at once.
Two caveats belong right next to that chart. In the same series, a five-minute sustained test with 200 users, Caddy failed to finish at its default settings, and so did Apache; only NGINX and OpenLiteSpeed completed it [4]. And inside JinnPanel, Caddy never serves a customer's files itself. It hands them to that account's own nginx. That extra hop is the price of isolation, and the chart above does not charge it.
Speed is not the whole bill. In September 2026, TechPlained measured memory on one Linux host serving the same 1 KB file, and Caddy came out the heaviest of the three: 113.6 MiB at idle, against 34.2 MiB for Apache and 8.3 MiB for nginx. Under 400 connections Apache nearly doubled, to 65.6 MiB, while Caddy barely moved, to 119.0 MiB [5]. JinnPanel pays for that Go runtime once per server, plus one small nginx per account.
The same author refused to publish requests-per-second figures at all, because on that test rig the virtual network, not the servers, set the ceiling [5]. Carry that warning into every chart in this article. Mine included.
DNS tells a sharper story. Gábor Lencse's 2020 study in IEEE Access tested BIND, NSD, Knot DNS and YADIFA using the RFC 8219 method, and found that Knot and NSD can reach roughly an order of magnitude higher performance than BIND [6]. Growing the zone file seriously hurt only one of the four. BIND.
Plesk and HestiaCP still run BIND. cPanel now defaults to PowerDNS [7], which Lencse did not test, so I won't invent a number for it.
Mail is where the old stack still wins, and I would rather say so than bury it. A 2026 evaluation by Tobias Weiß, pitting Stalwart 0.16.6 against Dovecot 2.4 CE on Kubernetes, found Dovecot faster at raw IMAP operations. Stalwart was 3 to 13 times faster at full-text search and used 2.4 times less memory [8]. One evaluation, one environment. Treat it as a direction, not a verdict.
The trend line matters as much as the snapshot. In August 2023, a user reading message headers from an early Stalwart got 50 to 60 messages a second, while Dovecot on the same machine read 1,100 to 1,300. The culprit turned out to be one missing socket flag,
PHP is where the comparison stops being about speed and starts being about defaults. cPanel offers six PHP handlers, from CGI and suPHP through LSAPI to PHP-FPM [10]. Whether new accounts get PHP-FPM is a server-wide switch, and cPanel's own API documentation recommends turning it on only with at least 2 GB of RAM available, or 30 MB per domain [11]. JinnPanel has no switch. Every account gets its own PHP-FPM pool, running as its own Linux user, from the first minute.
File transfer has the cleanest independent numbers I found. In August 2026, AIMultiple benchmarked eight SFTP servers on the same 8-core machine, three runs each, median kept. SFTPGo, which JinnPanel uses, posted the fastest handshake in the field at 25 ms (p50) and held 0.091 MB of memory per session. OpenSSH, the reference SFTP server that ships with practically every Linux distribution, held 13.283 MB per session [12].
Run that arithmetic on a busy afternoon. A hundred open SFTP sessions cost about 1.3 GB on OpenSSH and about 9 MB on SFTPGo. That is the difference between a truck and a bicycle parked in the same garage.
OpenSSH still won two rounds, and they belong in the record. It handled small files fastest, at 4,466 files a second, and burned the least CPU per gigabit transferred [12]. The test also ran over loopback on memory-backed storage, so treat the absolute numbers as a lab result, not a promise about your network.
One honest gap remains. I could not find a rigorous, modern, head-to-head benchmark of Stalwart's SMTP delivery against Exim, the mail transfer agent cPanel ships [3]. Without one, I make no claim.
Footprint is a draw. cPanel's own requirements ask for 2 GB of RAM and 20 GB of disk at minimum, with 4 GB and 40 GB recommended [13]. JinnPanel recommends 2 vCPU, 4 GB and 40 GB [2]. Same weight class.
But one line on that same cPanel page explains this entire article. cPanel requires SELinux to be disabled [13]. JinnPanel runs with it on, which is why two words in a terminal became an architecture instead of a switch I flipped.
JinnPanel's own end-to-end numbers, measured through the full path from Caddy to a customer's PHP pool, are the next thing worth measuring.
A panel that hides its limits is a panel that will surprise you at the worst possible hour. So here is the list, in plain words.
JinnPanel runs on one server. There is no clustering, no DNS secondaries on other machines, no failover. It runs only on AlmaLinux 10, and it expects the box to itself. There are no per-account CPU or RAM limits yet, because there are no cgroups or LVE; PHP pools are capped by process count and
It hosts PHP and nothing else, so Node.js and Python apps will have to wait. Files move over SFTP and SCP, never plain FTP. Backups are daily full copies, not incremental. There is no billing integration with WHMCS, no external API and no app installer. DNSSEC, uploaded custom certificates and per-mailbox quotas are not there yet either.
The admin side has gaps I feel every week. WHM cannot yet edit an existing account or "log in as" a customer, there is no "forgot password" flow, and there is only one admin account.
The status is public beta. Everything described in this article is running on a production server today, but the project was born in 2026, and support is community support. Read the security policy before you host anyone else's website on it.
I would rather you trust it slowly than trust it blindly.
You need a fresh AlmaLinux 10 x86_64 server with at least 2 vCPU, 4 GB of RAM and 40 GB of disk. As root:
When it finishes, it prints the nameserver and glue records to set at your registrar, plus a one-time setup token. Open
The code, the architecture notes and the full comparison with cPanel, Plesk, DirectAdmin, CyberPanel and others are on GitHub. Contributions are welcome. Security issues go through the private channel in
"Access denied" still shows up in my logs every now and then. It used to mean I was stuck.
Now it means the walls are holding.
All links checked on 4 October 2026.
Two words in the terminal, and my hosting panel stopped dead.
I had asked FrankenPHP, the web server running the panel, to do something every control panel on earth does a hundred times a day. Restart a service. It refused. I asked it to read a service log from the systemd journal, and it refused that too. I tried writing a
php.ini into /etc, and the filesystem looked back at me like a steel door with no keyhole.Every engineer who has fought SELinux knows the instinct that came next. Find the switch. Turn it off. Move on.
I didn't.
The longer I stared at those denials, the clearer it became that nothing was broken.
ProtectSystem=full had made /etc read-only for the entire process tree. SELinux was refusing to let the web server talk to systemd over D-Bus at all. The most exposed process on any hosting box had been put on a short leash, on purpose, by people who knew exactly what they were doing [1].The problem was mine. I was trying to build a hosting panel through the leash.
That single moment decided the architecture of JinnPanel, the free, open-source WHM/cPanel-style control panel I have just released as a public beta. Everything else in this article grew out of it.
Hosting still pays rent on software it doesn't own
I have spent fourteen years shipping software, more than twenty products of it, and a surprising amount of that work has ended up living on a server with a control panel licence attached to it. The panel is the part nobody brags about. It is also the part that sends an invoice every single month.
cPanel & WHM starts at roughly $27 a month per server [2]. Real per-account isolation on top of it usually means CloudLinux, which is another line on the bill. Running a small hosting business this way is like renting the keys to your own house, monthly, from someone who has never lived in it.
So I built my own house.
JinnPanel manages a single AlmaLinux 10 server end to end: resellers, hosting accounts, domains, email, DNS, databases, SFTP, backups, and one-click migration out of cPanel. It is MIT licensed. No per-account fees, no closed modules, no "premium edition" hiding the feature you actually need.
The stack is small and deliberately modern. FrankenPHP (built on Caddy) sits at the front. PHP-FPM runs customer code. MariaDB holds the data, Stalwart handles mail, Knot DNS answers queries, SFTPGo moves files, and Valkey caches objects. The panel itself is plain PHP and Tailwind. No framework. No Composer.
That last choice is not nostalgia. A hosting panel runs as close to root as software gets, and I wanted anyone who installs it to be able to open the code that is running their server and actually read it.
One script installs the whole thing on a fresh box. No prompts. Every internal credential is generated randomly, and no admin password is ever baked into the installer or the repository.
Don't break the sandbox. Build a window in it.
Back to those two words. Once I accepted that the web server should never do privileged work, the question became simple. Who does it instead?
The answer is a small PHP script called the root worker. A systemd timer runs it every five seconds, as root, spawned by PID 1, completely outside FrankenPHP's process tree. The web app never restarts anything, never touches
/etc, never calls systemctl. It writes a small JSON job file into a queue folder and walks away. The worker picks the job up, applies it, and deletes the file.Think of a bank teller behind thick glass. You slide a signed form under the window. The teller checks the signature, checks that the form is one they recognise, and only then walks to the vault. The vault never opens to the lobby.
That glass matters, because the queue folder is writable by the web server, and anything the web server can write, an attacker who compromises it can write too. So the worker trusts job files as little as possible. Every job is signed with an HMAC key derived from the app's secret. It must be a regular file owned by the web server user or root, never a symlink. Settings jobs accept only a fixed list of keys, each with its own expected value shape. Account jobs carry nothing but an ID, and the worker reads everything else from the database itself.
Every "Save & restart" button in the panel goes through this queue. So does every DNS zone, every new account, every domain change.
The same worker solves the read side of the problem. FrankenPHP cannot read the systemd journal, so on every cycle the worker snapshots the last 200 lines of each service's log into a root-owned folder, and the admin dashboard simply reads a plain file.
There was one more wall, and this one was stranger. Forking a child process from FrankenPHP and having that child connect to a Unix domain socket failed with
EPERM, reliably. The identical command worked from plain php-cli. It worked through nsenter into the exact same namespaces. It even failed with SELinux switched to fully permissive. It looks like a quirk of forking from a multi-threaded Go process with PHP embedded inside it, not anything I had configured.It is why Knot DNS's
knotc tool, which talks over a Unix socket, can never be called from the web app directly. Another job for the worker.Long-running work follows the same rule, one step further. A cPanel migration can take hours for a single account, so it runs as its own transient systemd unit. Not as root, because everything it unpacks came from somebody else's server. Not as a child of the web server, because no web request should live for hours.
The rule is simple. Privileged or long work never happens inside a request.
Every customer is a stranger to every other customer
Shared hosting is a building full of tenants who have never met and never should. One badly patched WordPress plugin in apartment 4B must not be able to walk into 7A and read the database password sitting in
wp-config.php.Most panels solve this with a paid kernel layer. JinnPanel solves it with the oldest security boundary Linux has. Users.
Every hosting account is its own Linux user,
jp_<username>, with a UID above 20000, no shell and a locked password. Its site folders belong to it, with mode 0750, so other accounts cannot even list them. Each account gets its own PHP-FPM pool running as that user, behind a socket only the web server can open. The pool is fenced with open_basedir to the account's own folders, and functions like exec and proc_open are disabled unless an admin explicitly allows them for that account.The part I am proudest of is the one nobody sees. Caddy never serves a customer's file contents. Not one byte. Every non-PHP request is handed to that account's own static file server, an nginx instance running as the account's Linux user, configured to refuse symlinks pointing at files the account doesn't own. If a customer plants a link to a neighbour's files, or to the panel's own config, nginx reads it with that customer's rights. It gets nothing.
Caddy is the concierge in the lobby. It knows which doors exist. It holds none of the keys.
The panel lives by the same rule. When a customer uses the File Manager, unzips an archive or clears OPcache, the panel does not reach into their folder with elevated rights. It sends a FastCGI request into the customer's own PHP pool, to a small agent that refuses anything a normal web request could carry. Files it creates belong to the customer, because the customer's own user created them.
Small details close the gaps between the big ones. The customer panel is served on every domain at port 2083, and since cookies are not scoped by port, the site blocks strip the panel's session cookie before a request ever reaches the customer's PHP. Caddy's admin API sits on a Unix socket, because on
127.0.0.1:2019 any local process could load a new config. And when an account is deleted, its site folders are moved into a root-only directory instead of being left behind, because files owned by a bare UID would quietly belong to whichever account received that UID next.No CloudLinux. No licence. Just users, pools and sockets, used the way they were designed to be used.
Mail should arrive, not merely send
Anyone who has run a mail server knows the old stack. Postfix for SMTP, Dovecot for IMAP, OpenDKIM for signing, Rspamd for spam, and a pile of flat config files holding them together like duct tape on a water pipe. It works. Until it doesn't, and then you spend a weekend reading headers.
JinnPanel uses Stalwart instead, a single Rust binary that does all four jobs and exposes a structured management API rather than text files [1]. The panel drives it over JMAP on loopback.
Every mail domain gets SPF, DKIM in both RSA and Ed25519, DMARC, MTA-STS, autoconfig and autodiscover, published automatically. Nobody has to remember to add the DMARC record. A daily timer re-syncs the records, copies the web server's certificate to Stalwart and keeps the submission port alive. Webmail comes included.
Stalwart also gave me a gift I didn't expect. Its settings are described by a live schema, so the panel's mail configuration screens are generated from that schema instead of hand-built. The admin sees 27 settings objects today. Adding another is one line of code, not one more form.
DNS follows the same philosophy. The panel's database is the single source of truth, and zone files are rendered from it. Every change bumps the serial and goes through the root worker, which writes the zone, asks Knot to reload it, and restores the previous file if Knot rejects the new one. A bad record never takes a domain offline.
HTTPS has no custom code at all. Caddy's automatic HTTPS engine is mature, so the panel simply hands it the domain. The moment a domain points at the server with ports 80 and 443 reachable, Let's Encrypt issues the certificate. There is no button to press.
And suspension actually suspends. Sites return 503, PHP pools stop, mail logins are refused, SFTP is disabled, MySQL users are locked, the cache login is switched off, cron jobs are skipped and panel sessions end. One click, everywhere at once. Unsuspending reverses every step.
Leaving should never cost a ransom
A free panel that nobody can move into is a museum piece. The real lock-in in hosting has never been the licence. It is the fear of the move.
So migration is built in, and it is free. JinnPanel can pull accounts from a live cPanel/WHM server, as a single account, as a reseller, or as an entire server through WHM root. It can also restore from cPanel backup files or from S3.
What comes across is the whole life of an account, not just its files. Sites, databases, mailboxes along with the mail already stored in them, DNS records, cron jobs, forwarders, autoresponders. Even
.htaccess rules, translated into routing rules for the new web server and validated before they are written. Imported mail password hashes are accepted as they are, so customers log in the next morning with the same password they used the night before.Under the hood, the panel only validates the request and records it. The root worker launches a separate migration runner that asks the source server for a full backup, receives it either by download or through a single-use SFTP user, then restores it through the exact same services the panel uses for everything else. Every name and path inside the backup is validated before it touches the disk. A heartbeat notices if the runner dies, and a half-restored account rolls back cleanly. The source server's credentials are encrypted with AES-256-GCM and wiped the moment they are no longer needed.
Now the honest part. The backup-file path has been proven on a real cPanel server's archives. The live API transfer has not yet been run against a real cPanel server [2]. If you have one to spare and want to break it, I would genuinely like to hear what happens.
Every part of the stack, laid on the table
Claims are cheap. Installers are not. So I went back to the one file that cannot exaggerate,
install.sh, and listed what it actually puts on a fresh AlmaLinux 10 box [15].FrankenPHP, built on Caddy, answers every web request and terminates TLS. PHP-FPM runs customer code, one pool per account per PHP version, with 8.5 as the default and 8.2, 8.3 and 8.4 installable beside it. nginx runs once per account to serve that account's static files. MariaDB holds the panel's state and every customer database. Stalwart handles all mail, SFTPGo handles file transfer, Knot DNS answers queries, and Valkey provides the object cache, with one locked-down login per account. Cypht serves webmail, phpMyAdmin sits behind single sign-on, and firewalld with fail2ban guards the doors. The installer also opens UDP 443, so HTTP/3 is on from the first boot [15].
Here is that stack set beside what the established panels ship.
| Component | JinnPanel | cPanel & WHM | Plesk | DirectAdmin | CyberPanel | HestiaCP |
|---|---|---|---|---|---|---|
| Web server | FrankenPHP (Caddy) in front; nginx per account for static files | Apache (EasyApache 4) | nginx + Apache | Apache, nginx, LiteSpeed or OpenLiteSpeed | OpenLiteSpeed / LiteSpeed | nginx (+ Apache) |
| PHP | PHP-FPM, one pool per account per version (8.2–8.5) | PHP-FPM, LSAPI, CGI, suPHP and more | PHP-FPM | PHP-FPM or CGI | LSAPI | PHP-FPM |
| | Stalwart (SMTP, IMAP, POP3, JMAP, Sieve in one binary) | Exim + Dovecot | Postfix + Dovecot | Exim + Dovecot | Postfix | Exim + Dovecot |
| Webmail | Cypht | Roundcube | Roundcube | Roundcube | Own client; Roundcube paid | Roundcube / SnappyMail |
| DNS | Knot DNS | PowerDNS (BIND optional) | BIND | BIND | PowerDNS | BIND |
| File transfer | SFTPGo (SFTP/SCP only) | Pure-FTPd / ProFTPD | ProFTPD | ProFTPD / Pure-FTPd | Pure-FTPd | vsftpd |
| TLS | Caddy automatic HTTPS | AutoSSL | Let's Encrypt | Let's Encrypt | Let's Encrypt | Let's Encrypt |
| Panel code | Plain PHP, no framework | Perl/C, proprietary | Proprietary | Proprietary | Python/Django | PHP + Bash |
Sources: JinnPanel's installer [15]; other panels from the vendor pages collected in JinnPanel's comparison, checked 1 October 2026 [3], and cPanel's PHP handler documentation [10].
Read the mail row twice. Every other panel runs two or three daemons stitched together for mail. JinnPanel runs one. That is the whole philosophy of the stack in a single cell: fewer moving parts, each one managed through an API instead of a pile of config files.
Feature by feature, with the gaps left in
A comparison table that only lists wins is an advertisement. This one keeps the red marks, mine included. Every JinnPanel cell comes from its feature reference, which is written from the code [14]; every other cell comes from a vendor page or a cited source.
built in · partly, paid or with conditions · no · ? not confirmed from an official source (it does not mean no)| Feature | JinnPanel | cPanel & WHM | Plesk | DirectAdmin | CyberPanel | HestiaCP |
|---|---|---|---|---|---|---|
| Price | Free, MIT | From $27.46/mo | Paid, by domain count | From $5/mo | Free, paid add-ons | Free |
| Operating system | AlmaLinux 10 only | RHEL family + Ubuntu 24.04 | | | | Debian/Ubuntu only |
| Reseller accounts | | | Web Host edition only | | | |
| Per-account PHP isolation | Linux user + PHP-FPM pool | | | | | |
| CPU/RAM limits per account | | Needs CloudLinux | ? | cgroups v2 | ? | ? |
| Hard disk quotas | XFS, opt-in | | ? | | ? | ? |
| SPF + DKIM published automatically | DKIM in RSA and Ed25519 | | | DKIM when enabled server-wide | DKIM manager | |
| DMARC published automatically | p=quarantine | Manual | p=none, from DNS template | Custom DNS template | ? | p=quarantine |
| Webmail | Cypht | Roundcube | Roundcube | Roundcube | Own client; Roundcube paid | Roundcube / SnappyMail |
| Import from cPanel | Built in, free | Transfer Tool | Plesk Migrator | cpmove archives | | |
| Backups to S3-compatible storage | | | Extension | FTP/FTPS out of the box | Module | Via Rclone |
| Incremental backups | Daily full | | | Manual Borg setup | | Restic |
| Two-factor sign-in | Every role | | ? | | | |
| DNS clustering / secondaries | | | Extension | | ? | |
| Works with SELinux enforcing | | Must be disabled | ? | ? | ? | ? |
| Plain FTP | SFTP/SCP only | Off by default | | | | |
| App installer (WordPress etc.) | | Add-ons | | Add-ons | | |
| Billing integration / external API | | | | | ? | ? |
| Paid vendor support | Community | | | | Paid add-ons | |
Sources: JinnPanel [14] [15]; other panels per JinnPanel's comparison, checked 1 October 2026 [3], with the mail rows re-checked for this article: cPanel does not create DMARC [16], Plesk's DNS template includes a p=none DMARC record [17], DirectAdmin creates DKIM when it is enabled server-wide [18] and leaves DMARC to a custom DNS template [19], and HestiaCP's documented records include DMARC at p=quarantine [20]. SELinux: cPanel [13], JinnPanel [1] [15].
Count the
marks in my own column. Seven, plus a warning sign on the operating system. No CPU or RAM containment, no incremental backups, no DNS clustering, no plain FTP, no app installer, no billing API, no paid support, and only AlmaLinux 10. Those are not footnotes. They are the reasons a hosting company with ten thousand customers should not move tomorrow.Now look at what sits on the other side of the ledger. Most of it never fits in a checkbox, so here it is in plain words, each item taken from the code [14].
Suspension in JinnPanel is not a flag on a website. One click stops the account's sites with a 503, stops its PHP pools, refuses its mailbox logins while still accepting its incoming mail, disables its SFTP logins, locks every MySQL login and kills open connections, disables its Valkey login, skips its cron jobs and signs it out of the panel. Eight services, one switch, every step reversed on unsuspend.
Mail DNS is done for you down to the details most panels skip. Beyond SPF, DKIM and DMARC, every mail domain gets MTA-STS, TLS reporting, SRV records and autoconfig/autodiscover, so a phone or a desktop mail app sets itself up from an email address alone. Your own SPF or DMARC record always wins over the panel's.
The web server does not read
.htaccess, so JinnPanel translates it. The Routes page converts rewrites, redirects, access rules, ErrorDocument and Header lines into Caddy rules, lists anything it could not translate, and validates every save before it goes live. Turn on Follow .htaccess and the worker re-checks the files every minute, so when WordPress rewrites its permalinks, the site follows. A change it cannot translate exactly is never applied on its own; the domain is flagged for review instead.An exposed-files scanner walks each document root for things anyone could download: archives, database dumps, backup copies, logs, customer exports. One button moves them outside the web folder. Dotfiles like
.env and .git are never served at all.Caching comes in three layers per domain: a compressed static file cache, a page cache for anonymous visitors, and a Valkey object cache whose login cannot run
FLUSHALL, KEYS or CONFIG, with ready-made snippets for WordPress and Laravel.For the admin, the Stalwart settings screens are generated from the mail server's own schema, 27 settings objects with no hand-built forms. A Server Tweaks page reads the machine's cores, memory and disk and offers Balanced, Performance and Extreme profiles for MariaDB, PHP, OPcache, Stalwart and SFTPGo, showing the exact values before applying them. Live logs for every service sit on the dashboard, and every sign-in and every change lands in a searchable activity log with the source IP.
None of these make JinnPanel bigger than cPanel. They make it sharper in the places where small hosting operators actually bleed.
The numbers belong to the parts, not the panel
HackerNoon readers check numbers, so let me be exact about these. Nobody has load-tested JinnPanel end to end yet, me included. What does exist is a body of independent, published benchmarks for the parts it is built from. Read what follows as a dyno sheet for the engine. It is not a lap time for the car.
The engine still matters. Every hosting panel is a bet on a stack. cPanel ships Apache through EasyApache 4 for the web, Exim and Dovecot for mail, and PowerDNS for DNS with BIND as an option. Plesk and HestiaCP lean on Apache, NGINX and BIND. CyberPanel is built on OpenLiteSpeed [3]. JinnPanel bets on Caddy, nginx, Stalwart and Knot.
Start with the front door. In 2025, LinuxConfig.org benchmarked six web servers on identical Debian 12 virtual machines, every one left on its default configuration, then held each under 500 concurrent connections for a full minute [4].
Under light load, the gap vanishes. Serving one small HTML page to 100 concurrent users, Apache managed 7,508 requests per second and Caddy 7,532 [4]. A rounding error. The difference only opens as connections pile up, which is exactly what a shared server looks like when many of its sites get busy at once.
Two caveats belong right next to that chart. In the same series, a five-minute sustained test with 200 users, Caddy failed to finish at its default settings, and so did Apache; only NGINX and OpenLiteSpeed completed it [4]. And inside JinnPanel, Caddy never serves a customer's files itself. It hands them to that account's own nginx. That extra hop is the price of isolation, and the chart above does not charge it.
Speed is not the whole bill. In September 2026, TechPlained measured memory on one Linux host serving the same 1 KB file, and Caddy came out the heaviest of the three: 113.6 MiB at idle, against 34.2 MiB for Apache and 8.3 MiB for nginx. Under 400 connections Apache nearly doubled, to 65.6 MiB, while Caddy barely moved, to 119.0 MiB [5]. JinnPanel pays for that Go runtime once per server, plus one small nginx per account.
The same author refused to publish requests-per-second figures at all, because on that test rig the virtual network, not the servers, set the ceiling [5]. Carry that warning into every chart in this article. Mine included.
DNS tells a sharper story. Gábor Lencse's 2020 study in IEEE Access tested BIND, NSD, Knot DNS and YADIFA using the RFC 8219 method, and found that Knot and NSD can reach roughly an order of magnitude higher performance than BIND [6]. Growing the zone file seriously hurt only one of the four. BIND.
Plesk and HestiaCP still run BIND. cPanel now defaults to PowerDNS [7], which Lencse did not test, so I won't invent a number for it.
Mail is where the old stack still wins, and I would rather say so than bury it. A 2026 evaluation by Tobias Weiß, pitting Stalwart 0.16.6 against Dovecot 2.4 CE on Kubernetes, found Dovecot faster at raw IMAP operations. Stalwart was 3 to 13 times faster at full-text search and used 2.4 times less memory [8]. One evaluation, one environment. Treat it as a direction, not a verdict.
The trend line matters as much as the snapshot. In August 2023, a user reading message headers from an early Stalwart got 50 to 60 messages a second, while Dovecot on the same machine read 1,100 to 1,300. The culprit turned out to be one missing socket flag,
TCP_NODELAY. With that single line fixed, a release build reached about 1,600 messages a second locally [9]. Young software is slow in fixable ways. Old software is fast in ways that took twenty years to earn.PHP is where the comparison stops being about speed and starts being about defaults. cPanel offers six PHP handlers, from CGI and suPHP through LSAPI to PHP-FPM [10]. Whether new accounts get PHP-FPM is a server-wide switch, and cPanel's own API documentation recommends turning it on only with at least 2 GB of RAM available, or 30 MB per domain [11]. JinnPanel has no switch. Every account gets its own PHP-FPM pool, running as its own Linux user, from the first minute.
File transfer has the cleanest independent numbers I found. In August 2026, AIMultiple benchmarked eight SFTP servers on the same 8-core machine, three runs each, median kept. SFTPGo, which JinnPanel uses, posted the fastest handshake in the field at 25 ms (p50) and held 0.091 MB of memory per session. OpenSSH, the reference SFTP server that ships with practically every Linux distribution, held 13.283 MB per session [12].
Run that arithmetic on a busy afternoon. A hundred open SFTP sessions cost about 1.3 GB on OpenSSH and about 9 MB on SFTPGo. That is the difference between a truck and a bicycle parked in the same garage.
OpenSSH still won two rounds, and they belong in the record. It handled small files fastest, at 4,466 files a second, and burned the least CPU per gigabit transferred [12]. The test also ran over loopback on memory-backed storage, so treat the absolute numbers as a lab result, not a promise about your network.
One honest gap remains. I could not find a rigorous, modern, head-to-head benchmark of Stalwart's SMTP delivery against Exim, the mail transfer agent cPanel ships [3]. Without one, I make no claim.
Footprint is a draw. cPanel's own requirements ask for 2 GB of RAM and 20 GB of disk at minimum, with 4 GB and 40 GB recommended [13]. JinnPanel recommends 2 vCPU, 4 GB and 40 GB [2]. Same weight class.
But one line on that same cPanel page explains this entire article. cPanel requires SELinux to be disabled [13]. JinnPanel runs with it on, which is why two words in a terminal became an architecture instead of a switch I flipped.
JinnPanel's own end-to-end numbers, measured through the full path from Caddy to a customer's PHP pool, are the next thing worth measuring.
What it cannot do yet
A panel that hides its limits is a panel that will surprise you at the worst possible hour. So here is the list, in plain words.
JinnPanel runs on one server. There is no clustering, no DNS secondaries on other machines, no failover. It runs only on AlmaLinux 10, and it expects the box to itself. There are no per-account CPU or RAM limits yet, because there are no cgroups or LVE; PHP pools are capped by process count and
memory_limit only.It hosts PHP and nothing else, so Node.js and Python apps will have to wait. Files move over SFTP and SCP, never plain FTP. Backups are daily full copies, not incremental. There is no billing integration with WHMCS, no external API and no app installer. DNSSEC, uploaded custom certificates and per-mailbox quotas are not there yet either.
The admin side has gaps I feel every week. WHM cannot yet edit an existing account or "log in as" a customer, there is no "forgot password" flow, and there is only one admin account.
The status is public beta. Everything described in this article is running on a production server today, but the project was born in 2026, and support is community support. Read the security policy before you host anyone else's website on it.
I would rather you trust it slowly than trust it blindly.
Try it, read it, break it
You need a fresh AlmaLinux 10 x86_64 server with at least 2 vCPU, 4 GB of RAM and 40 GB of disk. As root:
Code:
dnf -y install git
git clone https://github.com/th3n00bc0d3r/Jinn-Panel.git /opt/jinnpanel
cd /opt/jinnpanel/installer
JINNPANEL_HOSTNAME=server.example.com JINNPANEL_XFS_QUOTA=1 ./install.shWhen it finishes, it prints the nameserver and glue records to set at your registrar, plus a one-time setup token. Open
https://panel.server.example.com/setup, enter the token, and create your administrator. Upgrading is a git pull and running the installer again; it keeps all your data and secrets.The code, the architecture notes and the full comparison with cPanel, Plesk, DirectAdmin, CyberPanel and others are on GitHub. Contributions are welcome. Security issues go through the private channel in
SECURITY.md, not a public issue."Access denied" still shows up in my logs every now and then. It used to mean I was stuck.
Now it means the walls are holding.
References
All links checked on 4 October 2026.
- Bilal, M. JinnPanel Architecture (
docs/ARCHITECTURE.md). GitHub, 2026. github.com/th3n00bc0d3r/Jinn-Panel/blob/main/docs/ARCHITECTURE.md - Bilal, M. JinnPanel README: features, comparison chart (vendor prices checked 1 October 2026), requirements and known limitations. GitHub, 2026. github.com/th3n00bc0d3r/Jinn-Panel
- Bilal, M. How JinnPanel compares (
docs/COMPARISON.md): web, mail, DNS and SFTP stacks of cPanel, Plesk, CyberPanel, HestiaCP and ISPConfig. GitHub, 2026. github.com/th3n00bc0d3r/Jinn-Panel/blob/main/docs/COMPARISON.md - Rendek, L. Ultimate Web Server Benchmark: Apache, NGINX, LiteSpeed, OpenLiteSpeed, Caddy & Lighttpd Compared. LinuxConfig.org, 2025 (updated 21 September 2025). Tests 1, 5 and 8. linuxconfig.org
- Patel, A. Nginx vs Apache vs Caddy: Which Web Server Is Best? TechPlained, 2025 (memory measured 13 September 2026). techplained.com
- Lencse, G. "Benchmarking Authoritative DNS Servers." IEEE Access, vol. 8, pp. 130224–130238, 2020. doi:10.1109/ACCESS.2020.3009141
- cPanel, L.L.C. Nameserver Selection (WHM documentation, versions 106 and later). docs.cpanel.net
- Weiß, T. Stalwart vs Dovecot 2.4 CE: A Head-to-Head Mail Server Evaluation on Kubernetes. 2026. The page returned HTTP 404 on 4 October 2026; figures are taken from its indexed text. tobias-weiss.org/content/devops/dovecot-vs-stalwart-imap-production-comparison/
- Stalwart Labs. Performance question, GitHub Discussion #40, August 2023. github.com/stalwartlabs/stalwart/discussions/40
- cPanel, L.L.C. PHP Handlers (EasyApache 4 documentation). docs.cpanel.net
- cPanel, L.L.C. Enable PHP-FPM on new cPanel accounts and domains (WHM API 1,
php_set_default_accounts_to_fpm). api.docs.cpanel.net - Dilmegani, C. & Ermut, S. Top 8 SFTP Server Software. AIMultiple, 20 August 2026. aimultiple.com
- cPanel, L.L.C. Installation Guide: System Requirements for AlmaLinux OS. docs.cpanel.net
- Bilal, M. JinnPanel Features (
docs/FEATURES.md), a screen-by-screen reference written from the code. GitHub, 2026. github.com/th3n00bc0d3r/Jinn-Panel/blob/main/docs/FEATURES.md - Bilal, M. JinnPanel installer (
installer/install.sh). GitHub, 2026. github.com/th3n00bc0d3r/Jinn-Panel - hosting.com. Email authentication: SPF, DKIM and DMARC (states that cPanel does not create DMARC). kb.hosting.com
- Plesk International GmbH. Enabling DKIM Email Signing (Plesk Obsidian customer guide; default DMARC record
v=DMARC1; p=none). docs.plesk.com - KnownHost. Enabling DKIM with DirectAdmin (
dkim=1creates DKIM records for new domains). knownhost.com - DirectAdmin Forums. Integrate DMARC and DKIM into DirectAdmin Automatically (DMARC via custom DNS template). forum.directadmin.com
- HestiaCP. Email and mail server (documented DNS records include
_dmarcatp=quarantine). hestiacp.com