Hestia R* Edition

It didn't stay a fork.

HestiaRE started as a fork of HestiaCP. What it's becoming is something else: a stripped-down, dependency-light base that isn't trying to be a drop-in HestiaCP replacement. It's trying to be easy to fork again.

Most self-hosted panel projects accumulate dependent users, people running someone else's release pipeline, someone else's apt repository, someone else's opinions about what belongs in the stack. The day that project changes direction, they have nowhere to go, because they never had the pieces in their hands. HestiaRE inverts that. It doesn't want dependent users, it wants to make it cheap for someone else to run their own variant.

No compiled binaries, no custom apt repository, no build step required on the target host. Just source, a git tag, and a single tarball a bootstrap script extracts and hands off to. Forking HestiaRE costs a git clone, not a release infrastructure.

It also follows exactly one set of requirements: the maintainer's. Features this fleet doesn't need don't get built, not later, not "PRs welcome". Bug reports against the four target systems are welcome, and so is anything that makes forking cheaper. For everything else, the honest answer is better than a maybe: fork it and build it there. Not "use my panel", but "take this and run your own".

What changed, at a glance.

The honest way to describe a fork is a diff. Here's the shape of it.

Up to three external repos. Often none.

HestiaCP bundles and compiles a lot of its own stack. HestiaRE inverts that: OS repositories are the default, and every external source has to justify itself. What's left is at most three, all conditional: Sury when a box wants several PHP versions, MariaDB.org when a specific server version is chosen over the distribution's, and Docker when that addon is installed. A single-PHP box on the distribution's MariaDB adds none at all.

• Web, mail, database and firewall tooling, nginx, Apache, exim, dovecot, rspamd, phpMyAdmin, fail2ban, Composer, WP-CLI and more, come straight from distro packages.
• Optional components, ProFTPD, ClamAV, PostgreSQL, Redis, OpenSearch, Docker, restic, the file manager and more, are individually installable and removable, so a given host only carries what it actually uses.
• The result tracks the distributions' own security updates instead of a private package pipeline.

A git tag in, a tarball out.

HestiaCP builds versioned .deb packages, compiled binaries included, and serves them from its own apt repository. HestiaRE ships no packages and no binaries, only source.

• A version tag triggers CI, which refuses to release when the committed version and the tag disagree, and packs the tree into one versioned tarball with its checksum beside it.
• install.sh, the one curl-able bootstrap, fetches and extracts that tarball, runs a manifest-driven wizard and hands off to a non-interactive, idempotent installer.
• hestia update does the same for an installed box: it fetches and verifies the next release, unpacks it over the tree, and works through what the update manifests say an older box still has to catch up on.
• hestiare.com mirrors the release assets as a fallback. That matters in exactly one case, an IPv6-only host, because github.com has no AAAA record. A fork points it at its own mirror or drops it.

Four targets, equal priority.

Every feature is expected to work identically across all four, and every release is measured on all four before it is cut. None is a second-class target.

Nearly all of it is in place: installer, panel, web, mail, backup, firewall, CrowdSec, Docker, IPv6. This site itself runs on a HestiaRE box, kept current through the regular update path.

Human-reviewed, agent-assisted.

HestiaRE is developed through agentic AI-assisted development. An AI agent (Claude) writes and iterates on code, scripts, and documentation, while every change is reviewed, tested, and merged exclusively by a human maintainer. No commit reaches main without human review. The agent proposes, the human decides.