OpenPanel gives every hosting customer their own containers instead of a shared runtime

Isolation per user, not a shared Apache and MySQL

OpenPanel is a web hosting control panel built around containers, and the pitch is in the first line of the README: every user gets a fully isolated environment with a dedicated web server, dedicated database, private network and scoped file storage, delivering VPS-grade security on shared hardware.

The comparison the project draws is with traditional control panels. Those share a single Apache, MySQL or PHP runtime across all users, which means one customer's bad configuration, one customer's runaway script or one customer's traffic spike affects everyone else on the server. OpenPanel provisions a dedicated Podman context per user instead, with its own web server container, database container, PHP-FPM containers, private network and storage volume.

The result is described as VPS-level isolation on shared hosting infrastructure, without the VPS price tag.

That trade has a cost, and it is worth being clear about it. Containers isolate processes, but they do not by themselves isolate a kernel, so the isolation is at the container and network boundary rather than at the virtual machine boundary. What the design does buy you is per-user configuration freedom: a customer can run a different web server, a different database engine and several PHP versions at the same time, and a customer can exhaust their own CPU, memory or storage allocation without touching a neighbour.

The panel is written in Go, and the project is published as OpenPanel with a homepage at openpanel.com, with a free community edition and a fully supported commercial version.

The server runs Caddy, BIND9 and a shared phpMyAdmin

The architecture diagram in the README shows the OpenPanel server itself as a fixed set of services, and the separation from the per-user containers is the point.

On the server side sit the OpenPanel user control panel, the OpenAdmin administration panel, Caddy as reverse proxy and SSL terminator, BIND9 as the DNS server, phpMyAdmin shared by all users, and MySQL for user management and metadata. That last item is the one to notice: the metadata database is shared, while the customer databases are not.

Below that sit the user contexts, and the diagram shows three of them side by side with different choices in each. The first user runs Nginx with Varnish, hosting sites on PHP 8.4, PHP 8.2 and PHP 7.0, with a MySQL 8.0 database, 2 CPU cores, 4 GB of RAM and 50 GB of SSD storage. The second runs OpenLitespeed with Node.js 20.1 and PHP 8.3 sites, a MariaDB 10.11 database, 4 cores, 8 GB and 100 GB. The third runs Apache with Varnish, sites on PHP 8.1, PHP 7.0 and PHP 5.6, an api site on Python 3.11, Percona MySQL and PostgreSQL databases, 1 core, 2 GB and 25 GB.

Two details in that example matter more than the rest. A Node.js site and a Python site sit in the same per-user context as PHP sites, so the isolation model is about the container, not about one language. And a single user can have both Percona MySQL and PostgreSQL running side by side.

The user panel manages containers, the admin panel manages users

OpenPanel ships two interfaces, and the README draws the line between them.

OpenAdmin is the administrator-level interface, where you create and manage users, set up hosting plans and edit OpenPanel settings. OpenPanel is the client-level panel, the one end users log into, where they manage their own containers: edit settings, configure limits, manage backups, create websites and more.

The feature list for the customer side is where the panel gets concrete. Users can run multiple PHP versions, modify server configurations, view domain logs, restart services, set limits and configure backups. The design intent is stated as giving users full control over their environment, similar to a VPS experience, and the low-maintenance argument follows from that: each user manages their own services and their own backups rather than raising a ticket.

Every customer action is recorded, with a detailed activity log for user actions linked from the documentation.

For an operator, that split has a practical consequence. Routine account work, plan definitions and panel configuration all live in OpenAdmin, while the things customers complain about, logs, limits, backups and restarts, are handed to the customer. It is the difference between a panel that takes tickets and a panel that does not.

Billing connectors, cPanel imports and a white label interface

OpenPanel is aimed at a hosting business rather than at a hobbyist, and the commercial integration list is where that shows.

Billing integrations are documented for FOSSBilling, WHMCS, Blesta, and paymenter.org, and the last of those carries a footnote saying it is not actively maintained. If your business runs one of the first three, the panel has a documented path to it.

Migration is treated as a first-class operation, with documented instructions for importing accounts from cPanel backups and a separate project for CyberPanel backup imports. Given that the panel's model differs so much from a traditional shared runtime panel, migration is where a lot of the operational risk sits, and having tooling for both source systems is a meaningful part of the adoption decision.

There is also a white label option, so the panel can carry your own branding and user interface, and the documentation links to the customisation guide for it.

The security link in the feature list points to guidance on securing OpenPanel itself, which is a sensible thing for the project to publish, since the panel holds the credentials to every customer's environment and a compromise there is a compromise of the whole host.

A Go core with the OpenCLI, a panel frontend and translations

The repository root is a map of the product. There are openpanel/ and openadmin/ directories for the two interfaces, opencli/ for the command line side, integrations/ for the billing and service connectors, a caddy/ directory for the reverse proxy configuration, a mailserver/ directory and a vsftpd/ directory for the file transfer service, plus website/ for the marketing and documentation site and translations/ for the localisation files.

There is also a configuration/ directory, an UPDATES/ directory, a tests directory, a version/ directory and a scripts area, with .gitmodules for submodules, a babel.cfg, a cspell.json for spell checking and a tsconfig.build.json for the TypeScript build. The presence of tsconfig.build.json next to a Go project tells you the front end is TypeScript.

Two root files are worth calling out. There is a PODMAN_INSTALL.sh script, which is consistent with the panel provisioning Podman contexts, and there is a SECURITY.md for reporting vulnerabilities.

The licensing is a custom one that GitHub cannot classify, with the LICENSE file at the repository root, and the README notes the product is available both as a free community edition and as a fully supported commercial version. For a hosting business running customer environments, the terms of that custom licence are worth reading before you install it on production hardware, and this article is not legal advice on them.

On the release side, the tags show 2.0.16 on 2026-10-16, 2.0.15 on 2026-10-15 and 2.0.14 on 2026-10-05, and the last push to the main branch was on 2026-10-20, so the project is shipping frequently.

OS-agnostic is a claim with a test matrix behind it

The README calls OpenPanel a truly OS-agnostic control panel and then does something better than asserting it. It publishes a support matrix with the operating system, the version, the date it was last tested, the status and the average install time, generated between marker comments in the README so the table is refreshed automatically.

That table is the honest answer to the agnostic claim. Cross platform support in a panel like this is not free, because the components differ per platform: the reverse proxy, the DNS server, the mail server and the FTP daemon all have their own installation stories, and the container runtime itself has platform-specific packaging. Publishing a last tested date per operating system version is what lets an operator judge whether their platform is on a supported footing rather than a hopeful one.

It also tells you what to do before deploying. If your target operating system and version appear with a recent test date, the risk is lower than if the row is old or marked with a failure. The documentation links to the definition of OS-agnostic it is making the claim against, which is a small thing but tells you the project is trying to be precise rather than aspirational.

The panels themselves are the parts you interact with daily, and the split between OpenPanel and OpenAdmin is the one to internalise before you start.

Editorial conclusion

OpenPanel fits a hosting provider that wants to sell VPS-like isolation on shared hardware without running a virtual machine per customer, and it fits a team migrating accounts off cPanel or CyberPanel who need per-user web server, database and resource control. It is the wrong choice if you want a panel that runs on every operating system without testing, since the README lists a support matrix with per-version test results, and it is the wrong choice if your billing or automation needs a connector the project does not document. Verify first which operating systems and versions the support matrix currently lists as tested, that the licensing terms in the LICENSE file match what you expect for a commercial hosting operation, and how a customer migration behaves, since importing accounts is a separate operation from running the panel day to day.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. stefanpejcic/OpenPanel on GitHub