Hestia R* Edition
Rethink. Rebuild. Reboot. - pick your R*
A leaner, modernized fork of HestiaCP for self-hosted infrastructure. HestiaRE strips the codebase down to what's actually needed, replaces legacy bundled components with standard OS packages and modern lightweight alternatives (Caddy instead of the bundled nginx panel, Sury PHP instead of compiled PHP builds, distro repos instead of custom tarball installs), and rebuilds the installer as a composable, idempotent, pure-bash system.
It is deliberately scoped for a small, professional fleet, on the order of a few hundred domains across a couple dozen customers and servers, not for a broad community deployment.
Status: maturing
Nearly all of it is in place, and the test fleet has been through many rounds of it: installer, panel, web, mail, backup, firewall, CrowdSec, Docker, IPv6. Every subsystem exists, and every release is measured on all four target systems before it is cut. From v0.24 to v0.27 every command went through an audit: read, run on a box including its failure path, then fixed, tightened or removed. That makes HestiaRE usable.
It does not make it stable. Interfaces still move, any release can change behaviour, and v1 is deliberately far away, and the version number is not a countdown. Run it if you are willing to read a changelog and re-test after an update. Don't run it if you need something that stays put while you look elsewhere.
Target systems, all first-class, equal priority (every feature must work on all four):
- Debian 12 (Bookworm), Debian 13 (Trixie), Ubuntu 24.04 LTS (Noble), Ubuntu 26.04 LTS
Philosophy
HestiaRE does not want dependent users.
Most self-hosted panels accumulate them: people running someone else's release pipeline, someone else's apt repository, someone else's opinion about what belongs in the stack. The day that project changes direction or loses interest, its users have nowhere to go: they never had the pieces in their hands.
This one inverts that. No compiled binaries, no private package repository, no build step on the target host: source, a git tag, one tarball, a bootstrap script that extracts it. Forking HestiaRE costs a git clone, not a release infrastructure. That is the actual offer. Not "use my panel", but "take this and run your own".
It follows exactly one set of requirements: the maintainer's. This is a personal professional tool that happens to be open source. Features that this fleet does not need do not get built: not "later", not "PRs welcome", simply not here. Bug reports against the four target systems are welcome, and so is anything that makes forking cheaper. A feature request that only makes sense for someone else's fleet will be declined, quickly and without it being personal, because the honest answer is better than a maybe: fork it and build it there. Your fork, your opinions, without inheriting a toolchain you never signed up for.
That is also why the deliberate omissions below are not a backlog.
What makes it different
Reduced dependencies
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 that leaves is at most four external apt repos, all of them conditional: Sury when a box wants several PHP versions, MariaDB.org when a specific server version is chosen over the distribution's, nginx.org mainline on the latest preset, and the Docker repo when that addon is installed. A singlephp box on the OS MariaDB adds none at all.
- The panel runs on Caddy (OS repo) instead of a bundled nginx build.
- The panel PHP is the distribution's own, in isolated FPM pools instead of a custom compiled build. Sury is the option for multi-version PHP, not the default source:
singlephp never sets that repo up.
- Web, mail, database and firewall tooling (nginx, Apache, exim/dovecot/rspamd, phpMyAdmin, nftables, fail2ban, Composer, …) is installed straight from distro packages; only the
latest preset takes nginx from nginx.org. WP-CLI, which no distribution packages, comes as a release phar pinned by checksum.
- Optional components (ProFTPD, ClamAV, PostgreSQL, Redis, OpenSearch, Docker proxy, file manager, …) are individually installable and removable, so a given host only carries what it uses.
- IPv6 is first-class, never presupposed: a box with both families serves both, a v6-only box installs and runs from the bootstrap onwards, and a box whose kernel has no IPv6 is a supported state rather than an accident.
The result is a smaller, more auditable surface that tracks the distributions' own security updates instead of a private package pipeline.
A completely different build & release process
HestiaCP builds versioned Debian .deb packages (including compiled binaries) and serves them from a custom apt repository. HestiaRE ships no packages and no binaries, only source:
- Pushing a
v* git tag triggers CI (.github/workflows/release.yml).
- CI compares the committed
VERSION against the tag, refuses a release where the two disagree, and packs the tree into a single versioned hestiare-<version>.tar.gz source tarball with its .sha256 beside it.
install.sh, the one curl-able bootstrap, fetches and extracts that tarball into /usr/local/hestia, then takes over.hestia update does the same for an installed box: it names the target and asks, fetches and verifies the release, unpacks it over the tree, and works off what share/updates/ says a box coming from an older version still has to catch up on.
There is no compiled artifact, no private package repo, and no build toolchain required on the target host. (Earlier iterations used just/Make; that dependency has been removed, the installer is pure bash now.)
One piece of infrastructure does exist, and it is worth naming: hestiare.com mirrors this repository's release API and assets. It is a plain tarball mirror, not a package repo, and it is a fallback: the installer asks GitHub first and only falls back when that does not answer, which an empty HESTIARE_MIRROR in /etc/hestia/source.conf turns off entirely. It matters in exactly one case, an IPv6-only host, because github.com has no AAAA record. A fork does not inherit it: point the two literals at your own mirror, or drop it and lose nothing but the v6-only bootstrap.
Installer, refactored
Because there are no packages doing the setup work, the installer had to be rebuilt around that source-tarball model. It is now a clean two-stage flow:
install.sh (bootstrap): installs prerequisites, detects the OS, fetches and extracts the release, runs the interactive manifest-driven wizard (include/wizard.sh) which writes /etc/hestia/install.conf, and seeds /etc/hestia so the h-* commands can run.h-install-hestia (installer): non-interactive, reads install.conf, and is component-gated and idempotent: every subsystem is guarded by a flag, so presets (standard, compact, latest, singlephp, nomail, mailonly) and optional add-ons (via h-add-* / h-delete-*) compose cleanly and re-runs don't fight themselves.
A post-install smoke test then verifies that the services implied by the chosen configuration actually came up.
Deliberate omissions
Some HestiaCP subsystems are intentionally left out, not missing but decided against, to shrink the attack surface and the maintenance burden for the intended scale:
- No bundled DNS server (bind9): DNS is delegated to external / managed providers.
- No REST API.
- No Web Terminal.
The same reasoning removes vsftpd, SpamAssassin (rspamd is the mail-filter), and the Software Installer. These are settled decisions, not backlog items.
Development approach
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.
License
GPL-3.0, inherited from HestiaCP.
