HestiaCP vs Panelica: Modern Go Rewrite vs Vesta Fork

HestiaCP earned its base honestly

Before any comparison, a fair acknowledgment: HestiaCP is a genuinely useful panel. It ships a working LAMP/LEMP stack, handles DNS and mail, has a clean enough interface, and costs nothing. For a solo operator running a handful of personal projects on a VPS with 1-2 GB of RAM, it delivers. The community maintains it seriously, documentation is reasonable, and the idle footprint of roughly 50 MB is hard to argue with on minimal hardware.

This post is not about dismissing that. It is about a specific question: in 2026, when you are running 10-50 domains, perhaps starting to hand domains to clients, and want a panel architecture that can grow with you, does HestiaCP still fit? And how does its design compare to Panelica, which was written from scratch in 2024 as a commercial-grade, Go-based alternative to traditional panels including cPanel?

The answer depends on what you are actually building. Let us walk through it methodically.

The Vesta fork backstory

HestiaCP is a fork of VestaCP. VestaCP itself was an actively developed open-source panel that became widely adopted in the mid-2010s. In 2018, the VestaCP project effectively went inactive. Its installer had a documented supply-chain incident that year involving unauthorized code in the installation path. The incident is part of the public record and worth understanding as context, not as a way to discredit HestiaCP.

HestiaCP emerged as a clean fork, took the project seriously, stripped the problematic code, and continued development with proper community governance. That work has real value. The panel today is not the 2018 Vesta installer. It is a maintained, GPL v3 project at version 1.9.4, released July 21, 2025, with an active issue tracker and a community of contributors.

What HestiaCP inherited is the architectural approach: Bash scripts coordinating a vanilla stack. That heritage is neither good nor bad by itself. It becomes relevant when you ask how far the design can be extended before the seams show.

How the two panels are built

Architecture is the place where the two panels diverge most sharply. HestiaCP orchestrates stock system packages through Bash. Panelica ships a single Go 1.24 binary with a React 19 frontend. One approach reuses what Debian and Ubuntu already provide; the other replaces the control plane entirely.

The practical implications of these architecture choices run through every section below. Go compiles to a single static binary with no PHP control-plane overhead. The React 19 frontend communicates through 246 documented REST endpoints. HestiaCP's jQuery interface talks to system state directly through Bash-generated responses. Neither approach is inherently wrong, but they result in panels with different capabilities and different ceilings.

OS coverage: where each panel installs

HestiaCP explicitly documents that it does not support non-LTS operating systems. As of version 1.9.4, that means four supported distro versions: Debian 11, Debian 12, Ubuntu 22.04 LTS, and Ubuntu 24.04 LTS. Debian 13 is in community discussion for 1.9.5 but not available in the current stable release. There is no RHEL family support.

This matters most if you are running a hosting operation that needs to match client OS preferences, or if you are managing infrastructure that standardizes on RHEL-family distributions for compliance reasons. AlmaLinux and Rocky Linux have become the default choices for production workloads at many organizations since the CentOS lifecycle change. HestiaCP is not an option on those distributions; Panelica is.

For a personal VPS running Debian 12 or Ubuntu 24.04, this section is irrelevant. Both panels install fine.

The stack underneath: vanilla LAMP versus a single Go binary

HestiaCP installs and manages the packages your distribution already ships: Nginx, Apache, MariaDB (default), PHP from system repositories, Exim for mail. The panel is a management layer over those. When something fails, you troubleshoot it the same way you would troubleshoot any Debian system service. That familiarity is a genuine advantage.

The tradeoff is that the control plane itself is a collection of Bash scripts and a PHP-rendered web interface backed by configuration files. There is no unified API contract. The REST API capabilities that exist are partial and not fully documented. If you want to automate domain provisioning, backup triggers, or user creation from an external system, you are working against what the design was built for.

Panelica's architecture starts from the opposite premise. The Go binary exposes 246 REST endpoints, all documented, all accessible through the same interface that the React frontend uses. Every operation the UI can perform, an API call can also perform. The services Panelica manages -- MySQL 8, PostgreSQL 17, Redis 7, Postfix, Dovecot, ProFTPD, BIND -- are isolated under /opt/panelica/, separate from the host OS package tree. That isolation makes the panel consistent across all eight supported distributions rather than adapting to each distro's packaging decisions.

The consequence for daily use: HestiaCP feels like a well-organized shell interface. Panelica feels like an application platform. Which you prefer depends on what you are building.

Why kernel isolation matters when you start hosting clients

Most single-operator VPS owners do not think about isolation until they have a second user on the same machine. Then it matters a lot.

HestiaCP provides two isolation mechanisms: PHP-FPM pools (a separate process pool per user, with open_basedir limiting filesystem access) and standard Unix permissions (separate UID/GID per user, file ownership enforced). These are the same two mechanisms any standard LAMP server provides. They are not nothing -- PHP-FPM pools in particular catch a meaningful category of cross-site script access. But they do not prevent a compromised PHP process from consuming all CPU and memory on the machine, and they do not prevent namespace-level interference between users.

Panelica adds three kernel-level layers on top of what HestiaCP provides. Cgroups v2 limits how much CPU, memory, I/O, and process count any single user can consume -- so a runaway PHP script cannot starve every other site on the machine. Linux namespaces give each user their own PID and mount view, so processes in one user's space cannot interact with another's. SSH chroot jails mean SFTP users land in their own isolated directory tree and cannot traverse to other users' home directories.

These three layers are default on every Panelica plan, including the free tier. They are not premium add-ons. If you are running a personal project on a dedicated machine you control entirely, they add overhead without benefit. If you are hosting a second client, they become load-bearing infrastructure.

Multi-tenant reality: single admin versus four-level RBAC

HestiaCP has a single administrator model. There is one admin account with full control over the panel. Individual users can be created and scoped to their domains, but there is no built-in reseller tier, no way to grant a customer limited administrative access to manage their own users, and no way to white-label the interface for a client-facing deployment.

Panelica ships a four-level RBAC structure: Root, Admin, Reseller, and User. A reseller account can create and manage users, apply resource quotas, and handle client operations without access to the underlying server. An admin can manage a subset of the infrastructure without root-level credentials. Each level sees only what it is permitted to see.

For a solo operator, this distinction is irrelevant. For anyone who has ever said "I need to give a client access to just their own sites without letting them see anything else," it is the practical boundary between HestiaCP and Panelica as a platform.

The 2026 stack pieces HestiaCP does not have

HestiaCP's feature set is focused: web, DNS, mail, FTP, databases. That focus is appropriate for what it is designed to do. The panels that have emerged in the last two years -- Panelica included -- have expanded the definition of what a hosting panel should manage.

Docker management: HestiaCP has no Docker integration. Panelica ships a full Docker manager with 160+ one-click application templates covering common self-hosted workloads. Containers run with per-container cgroup limits and integrate with the same SSL automation that domain provisioning uses.

Git deploy: HestiaCP has no built-in Git workflow. Panelica's Git Manager handles repository hosting, deploy hooks, and branch-to-directory mappings. The feature is covered in detail at Git, Built In: Why a 2026 cPanel alternative needs a first-class repository manager.

AI co-pilot: HestiaCP has no AI layer. Panelica ships OpsAI with 15 domain experts and coverage across 1,263 API endpoints. For operators who want to diagnose issues, generate configurations, or explore panel capabilities conversationally, this is a meaningfully different experience.

Native mobile apps: HestiaCP does not have a mobile application. Panelica has native iOS and Android apps that cover resource monitoring, domain management, backup status, and service control. For an operator who wants to check on a server from a phone at 2 AM, the difference is noticeable.

Languages: when "supports your language" means full UI parity

HestiaCP ships in English as the primary language and has community-contributed translations for roughly 15 languages. Community translations are partial: some strings are translated, others fall back to English, and coverage varies by language and by how recently the translation was updated.

Panelica ships 31 UI languages with full parity across all 22,323 translation keys. Every string in the interface -- labels, error messages, tooltips, modal content, table headers -- exists in all 31 languages. The translations are maintained in the codebase and updated with each release rather than contributed ad hoc by volunteers.

For a hosting operation serving customers in a non-English-speaking market, this is the difference between a panel that says it supports a language and a panel that actually does.

Memory and footprint: when HestiaCP is the right choice on minimal hardware

Let us be direct here: HestiaCP's idle footprint of approximately 50 MB is a real advantage on constrained hardware. If you are running a personal project on a $4/month VPS with 512 MB or 1 GB of RAM, HestiaCP leaves more memory for your application. Panelica's idle footprint is roughly 120 MB, which reflects the Go binary, the React frontend assets, the PostgreSQL instance, and the Redis cache that the panel requires.

On a VPS with 2 GB or more of RAM -- the realistic minimum for running a small number of active websites -- the difference becomes less significant. On dedicated hardware or a VPS provisioned for real workloads, it does not matter. But on truly minimal hardware, the HestiaCP architecture is genuinely lighter, and this guide would not be honest if it glossed over that.

Feature-by-feature

Migration: moving from HestiaCP to Panelica

If you are currently running HestiaCP and want to evaluate Panelica without rebuilding everything by hand, the migration pipeline supports HestiaCP as a source. The 7-step process handles user creation, domain provisioning, file transfer via rsync, database import with preserved MySQL password hashes, email account migration, and SSL re-issuance. You can find the conceptual walkthrough at Migrating from cPanel to Panelica: a step-by-step walkthrough -- the same pipeline logic applies. For a full look at available migration sources, the panel comparison hub and the HestiaCP comparison page cover them specifically.

When HestiaCP still fits in 2026

HestiaCP is the right answer in specific, well-defined circumstances. If you are running personal projects on a VPS with under 1 GB of RAM and you need to minimize idle memory consumption, HestiaCP's ~50 MB footprint is a genuine advantage. If you are a single operator with no intention of ever adding a second admin or handing the panel to a client, the single-admin model is not a limitation. If you are on Debian 12 or Ubuntu 22.04/24.04 and have no plans to move to a RHEL-family distribution, the OS support gap does not affect you. If GPL v3 is important for your licensing requirements, HestiaCP is the only option between the two.

The panel has a track record, a community, and zero cost. For simple, stable, solo-operated hosting on Debian or Ubuntu, it is a reasonable choice and will likely remain one.

Choosing the right cPanel alternative for your scale

Both HestiaCP and Panelica are credible cPanel alternatives. The question is which alternative matches your current scale and where you expect to be in 18 months.

If you are managing one server for yourself, HestiaCP's lower resource footprint and simpler architecture may be all you need. If you are at the point where you are hosting sites for clients, want kernel-level isolation between users, need Docker for modern application workloads, require a documented API for automation, or want to work in a language other than English, Panelica addresses those requirements in ways HestiaCP's architecture does not.

Panelica ships a free tier with one domain and no time limit. If you are evaluating it as a cPanel alternative or as an upgrade from HestiaCP, you can install it and test it on real infrastructure before committing. The install script runs in under three minutes and the full feature set is available from day one.

For a broader look at the panel landscape in 2026, the best cPanel alternatives comparison covers eight panels including both HestiaCP and Panelica. The cPanel comparison and the full comparison hub at /compare are worth bookmarking if you are mid-evaluation. If regulatory alignment matters for your hosting operation, EU hosting companies replacing US-built panels in 2026 covers the NIS2 and Schrems II dimensions. The CyberPanel vs HestiaCP vs aaPanel comparison is the closest sister piece if you are specifically evaluating free panels.