HestiaRE

pre-v1 · usable, not stable · open source

Hestia R* Edition

Pick your R:

A leaner, decoupled rebuild of HestiaCP for small professional server fleets, and a foundation meant to be forked again by anyone who wants their own.

View source on GitHub See what changed
~/hestiare

$ git diff --stat hestiacp..hestiare

bind9, REST API, vsftpd, apt repo … 7
Caddy, rspamd, nftables, IPv6 … 13

20 changes, 13 insertions(+), 7 deletions(-)

$

Philosophy

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 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”.

Structural changes

What changed, at a glance.

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

hestiacp hestiare
  • bind9 (bundled DNS server)delegated to external / managed DNS
  • REST APIdeliberate omission
  • Web Terminaldeliberate omission
  • vsftpd, SpamAssassin, Software Installerreplaced or dropped
  • SnappyMailreplaced by Tachyon, a maintained fork
  • custom apt repo + compiled .deb packagesno private package pipeline
  • Make / just build toolchainpure bash now
  • Caddy as the panel frontendOS repo, not a bundled nginx build
  • distro PHP, isolated per-site FPM poolsSury only where a box wants several versions
  • rspamd as the mail filterOS repo, replaces SpamAssassin
  • per-customer file managerdedicated FPM pool, not a shared SFTP loopback
  • CrowdSec, HTTP ban layer, firewall-level bans, fleet peer-meshL7 + L3 + multi-server
  • native bot rate-limiting / WAF-lite layerworks even without CrowdSec installed
  • nftables firewallreplaces iptables, both address families
  • IPv6 first-classdual-stack, v6-only, or no v6 at all
  • per-customer Dockercompanion model, included in the backup
  • full, differential and restic backupsper customer, local or remote targets
  • restores HestiaCP backup archivesexisting boxes move over by restore
  • tarball-based updatesmanifest-driven catch-up, no packages
  • component-gated, idempotent bash installerprofiles + individually add/removable addons

Dependencies

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.

  1. Sury

    only when a box wants several PHP versions.

  2. MariaDB.org

    only when a specific server version is chosen over the distribution's.

  3. Docker

    only when that addon is installed.

  4. None at all

    A single-PHP box on the distribution's MariaDB adds no external repository.

Straight from distro packages

Web, mail, database and firewall tooling, nginx, Apache, exim, dovecot, rspamd, phpMyAdmin, fail2ban, Composer, WP-CLI and more.

Only what a host actually uses

Optional components, ProFTPD, ClamAV, PostgreSQL, Redis, OpenSearch, Docker, restic, the file manager and more, are individually installable and removable.

Distribution security updates

The result tracks the distributions' own security updates instead of a private package pipeline.

Releases & updates

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.

  1. git tag

    A version tag triggers CI, which refuses to release when the committed version and the tag disagree.

  2. tarball + checksum

    CI packs the tree into one versioned tarball with its checksum beside it.

  3. 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.

  4. hestia update

    Does the same for an installed box: 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.

Status

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.

  • Debian12Bookwormfirst-class
  • Debian13Trixiefirst-class
  • Ubuntu24.04LTS · Noblefirst-class
  • Ubuntu26.04LTSfirst-class

Nearly all of it is in place. This site itself runs on a HestiaRE box, kept current through the regular update path.

  • installer
  • panel
  • web
  • mail
  • backup
  • firewall
  • CrowdSec
  • Docker
  • IPv6

Development

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.

agent proposes
human decides
branch main