One Panel, One Update Channel: Unified Across the RHEL and Debian Families

For a long time, running a hosting panel on a non-standard Linux distribution meant accepting second-class treatment: delayed updates, missing packages, or support tickets that went nowhere. You picked your OS, then you picked your panel — and hoped they stayed compatible.

Panelica was built differently. The backend is a single statically-linked Go binary. It ships with its own NGINX, PHP, MySQL, PostgreSQL, Redis, BIND, and the rest — all isolated under /opt/panelica/, all managed by a single update channel. The OS beneath it is largely irrelevant to the panel's operation. That architectural decision is what makes broad multi-release support possible today.

AlmaLinux 9 and 10, Rocky Linux 9 and 10, Debian 12 and 13, Ubuntu 22.04 through 26.04 — they all receive the same panel version, the same security patches, and the same feature releases, at the same time, through the same Central update channel. This article explains what that means operationally and how it works under the hood.

For End Users and Operators

You Should Not Have to Choose a Panel Based on Your OS

Most panels on the market were built in an era when "Linux" effectively meant "CentOS" for hosting. That assumption is baked into their architecture: separate release tracks, OS-specific repositories, different support tiers. What that means in practice is that if you run Debian on your servers, or if your provider offers AlmaLinux, you end up with a different update cadence than customers on the "primary" OS.

Panelica does not work this way. There is one release, one tarball, one version number. Every supported release receives it simultaneously. You pick the OS that fits your infrastructure requirements — hardware vendor support, your team's familiarity, your compliance requirements — and the panel follows.

Your Subscription Does Not Change When Your OS Does

If you start on Ubuntu 22.04 LTS and your host later migrates infrastructure to AlmaLinux 9, your Panelica license travels with you. There is no OS-specific licensing tier, no re-activation, no support surcharge. The panel binary on AlmaLinux 9 is the same binary that ran on Ubuntu 22.04. Your data, your domains, your users, your configuration — all of it migrates intact.

This is not a marketing statement. It is a consequence of the architecture: services are isolated under /opt/panelica/, database files live in /opt/panelica/var/db/, and the installer does not depend on the host OS package manager for any panel-critical component.

For Hosting Companies: One Inventory, Any OS Mix

If you operate multiple servers — some on Debian for your European nodes, some on AlmaLinux for your US datacenter, some on Rocky Linux because a key enterprise customer requires RHEL-compatible infrastructure — you do not manage multiple panel products. You manage one. Updates roll out from the same Central dashboard to all nodes regardless of OS. Security patches reach AlmaLinux 9 and Debian 12 at the same time.

This also matters for your support workflow. When a customer submits a ticket, your team does not need to know which OS that server runs to navigate the panel interface. It looks the same. It behaves the same. Feature parity is complete across all supported releases.

Cross-OS Update Parity: What It Means for Security

When a CVE is disclosed that affects the panel, a patch is built once and deployed to all OS variants simultaneously. Under a per-OS-track model, a patch for CentOS Stream might ship days before the equivalent for Debian. During that window, Debian servers are vulnerable. With a single update channel, that window does not exist — the patch either reaches all supported releases or none.

This is not a hypothetical concern. The hosting industry experienced several high-severity vulnerabilities in 2026 that exposed exactly this gap in multi-track panels. Operators on secondary-support OSes waited longer for fixes. Panelica's architecture eliminates that class of delay.

Tenant Isolation Does Not Depend on CloudLinux

CloudLinux is a commercial Linux distribution that adds kernel-level per-user resource controls on top of CentOS/AlmaLinux. It is widely used in shared hosting because traditional panels rely on it for the isolation features they cannot build themselves. CloudLinux licensing costs roughly $14 per server per month on top of the panel license.

Panelica implements five-layer tenant isolation entirely through standard Linux kernel features: cgroups v2 for resource limits, Linux namespaces for process and filesystem isolation, SSH chroot jails, per-user PHP-FPM pools, and Unix UID/GID separation. None of these require a custom kernel or a commercial OS add-on. They work on stock Debian, Ubuntu, AlmaLinux, and Rocky Linux. CloudLinux is not needed.

Supported Linux Releases at a Glance

Panelica supports ten Linux releases across two OS families as of 2026-05-24:

• Debian 12 (Bookworm) and Debian 13 (Trixie)
• Ubuntu 22.04 LTS (Jammy), Ubuntu 24.04 LTS (Noble), and Ubuntu 26.04 LTS (Plucky)
• AlmaLinux 9 and AlmaLinux 10
• Rocky Linux 9 and Rocky Linux 10
• CentOS Stream 9

Minimum requirements remain consistent across all distributions: 1 CPU core, 1 GB RAM, 20 GB disk, root access, and a kernel with cgroups v2 enabled (default on all listed distributions).

Windows Server

Windows Server support is on the longer-term roadmap, contingent on enterprise demand over the next 12 months. All current development and all supported distributions are Linux-based.

For Sysadmins and Technical Readers

Architecture: Why OS-Agnosticism Is Structural, Not Bolted On

The Panelica backend is a single Go binary compiled against glibc 2.34 — the minimum glibc version present in AlmaLinux 9, Rocky Linux 9, and equivalent RHEL-family distributions. It ships with all required runtime libraries bundled. There is no dependency on the host OS's package manager for any panel-critical path.

Every managed service — NGINX, Apache, PHP (8.1 through 8.5), MySQL 8, PostgreSQL 17, Redis 7, BIND 9, Postfix, Dovecot, ProFTPD — runs from binaries under /opt/panelica/services/. Sockets, PID files, and logs live under /opt/panelica/var/. Configuration templates are generated by Panelica's config generator service; they do not depend on OS-level config paths like /etc/nginx/ or /etc/mysql/.

/opt/panelica/
  bin/           # panel binaries (panelica-server, pn-service, ...)
  services/      # nginx, apache, php/8.1-8.5, mysql, postgresql, redis, bind, ...
  etc/           # generated configs (panel-nginx, php-fpm-users, bind, ...)
  var/
    db/          # postgresql data, mysql data, redis dump
    run/         # unix sockets (mysqld.sock, redis.sock, php-fpm-*.sock)
    logs/        # per-service log directories
    www/panel/   # frontend static files

The only host-OS touchpoints are: systemd unit files (installed to /etc/systemd/system/), fail2ban configuration (installed to /etc/fail2ban/), and PHP wrapper scripts in /usr/local/bin/ that set PHP_INI_SCAN_DIR to the Panelica-managed conf.d path. Everything else is self-contained.

GLIBC 2.34: The Compatibility Floor

All Panelica binaries are compiled inside an AlmaLinux 9 Docker container, which ships glibc 2.34. This is intentional: glibc is forward-compatible but not backward-compatible. A binary compiled on Ubuntu 26.04 (glibc 2.39) will fail with GLIBC_2.38 not found on AlmaLinux 9. The AlmaLinux 9 build environment guarantees that the compiled binary runs on any supported distribution without modification.

Verification after every build:

objdump -T bin/panelica-server | grep GLIBC | sort -V | tail -1
# Expected: GLIBC_2.34 or lower

This single constraint — compile inside glibc 2.34 target — is what makes the same binary work on Debian 12, Ubuntu 22.04, AlmaLinux 9, and Rocky Linux 9 without separate builds.

Package Management: Native apt and dnf Integration

During installation, Panelica's installer detects the host OS family and invokes the appropriate package manager for host-level dependencies: apt-get on Debian/Ubuntu, dnf on RHEL-family distributions. This covers packages like sshpass, rsync, curl, nftables, and fail2ban that must integrate with the host OS.

On RHEL-family systems, the installer handles EPEL repository differences between major versions automatically. EPEL 9 and EPEL 10 have different package availability; packages like yajl, opendkim, and redis have different names or availability across EPEL versions. The installer maps these differences without requiring operator intervention.

Centralized Update Channel

Updates are distributed through Panelica Central. When an update is published, it appears in the panel's Updates dashboard regardless of which OS the server runs. The update payload is a single tarball that replaces binaries and configuration templates. The apply step is:

panelica package apply
# or via the panel UI: Updates -> Apply

There is no per-OS package repository to configure, no OS-specific update channel to subscribe to. One Central, one tarball, all supported releases updated simultaneously.

Cgroups v2: The Prerequisite for Kernel Isolation

Panelica's isolation model requires cgroups v2. All supported releases enable cgroups v2 by default in their modern kernel releases: Debian 11+, Ubuntu 21.10+, AlmaLinux 9+, Rocky Linux 9+. There is no need to add systemd.unified_cgroup_hierarchy=1 to kernel parameters on any supported OS.

Per-user cgroup slices are created at /sys/fs/cgroup/panelica.slice/panelica-user.slice/panelica-user-{username}.slice/. Within each slice, four resources are controlled: cpu.max, memory.max, io.max, and pids.max. The same cgroup paths and controller names work identically across all supported releases because cgroups v2 is a kernel interface, not a distribution-specific feature.

PHP Isolation Across OS Families

Per-user PHP-FPM pools use a wrapper script pattern rather than symlinks. Each PHP version (8.1 through 8.5) has a wrapper in /usr/local/bin/php8X that sets PHP_INI_SCAN_DIR to the Panelica-managed path before invoking the bundled PHP binary. This prevents the host OS's PHP configuration directories from being picked up on Debian/Ubuntu systems, where /etc/php/X.Y/cli/conf.d/ would otherwise load conflicting extensions.

The pool configuration pattern is identical across OS families. The generated pool file differs only in the username and resource limits, not in OS-specific paths. This means the PHP isolation layer behaves identically on AlmaLinux 10 and Debian 13.

SELinux on RHEL-Family Releases

SELinux integration on RHEL-family releases (AlmaLinux, Rocky, CentOS Stream) currently ships in permissive mode by default; dedicated enforcing-mode integration is on the roadmap. The five-layer isolation model is active independently of SELinux state. See the AlmaLinux and Rocky Linux articles for details.

Systemd Units: Installed, Not Symlinked

Panelica installs systemd unit files as copies in /etc/systemd/system/, not as symlinks to /opt/panelica/etc/systemd/. This ensures that systemctl works correctly across all distributions, including those where symlinked unit files in non-standard paths can cause issues with security policies. On RHEL-family systems, this also avoids potential issues on symlink traversal under SELinux permissive mode.

OS Coverage Comparison

Get Started or Learn More

Install Panelica on any supported distribution with a single command:

curl -sSL https://latest.panelica.com/install.sh | bash

The installer detects your OS automatically. No flags required for standard configurations.

For deeper reading on specific distributions or side-by-side feature comparisons:

• AlmaLinux 9 and 10: First-Class Support on Panelica — EPEL differences, AlmaLinux 10 specifics, migration notes
• Rocky Linux 9 and 10: First-Class Support on Panelica — Rocky-specific notes, RESF governance, SCLO compatibility
• Panelica vs the alternatives — feature-by-feature comparison including OS support depth
• Best cPanel Alternatives in 2026 — broader panel landscape with OS support as one dimension