Built to be audited, not just trusted
Security is the core design constraint, not a checkbox. Here's how the architecture limits blast radius.
Least-privilege agent
The panel runs unprivileged. A root agent performs privileged actions only via a local socket, with a closed allowlist, HMAC signing, and a peer-UID gate — no arbitrary command execution.
Hardened network
UFW deny-by-default with only 22/80/443 open. PostgreSQL and MariaDB bind to loopback. The agent socket is not TCP-exposed.
Enforced admin 2FA
Admin accounts use password + TOTP; password-only login is rejected. App-level login rate-limiting is in place.
Verified updates
Update artifacts are checksum-verified against a trusted manifest before anything is applied — never a force reinstall.
Backups & rollback
Nightly checksummed local backups and a documented, reversible upgrade path with retained rollback assets.
Scoped RBAC
A least-privilege app_tester role restricted to the Applications Center — no admin, server, DNS, backups, or updates.
Security posture at a glance
| Control | State |
|---|---|
| Firewall (UFW) | Active, deny-by-default — only 22 / 80 / 443 |
| Panel bind | Loopback (127.0.0.1) behind nginx |
| Databases | PostgreSQL + MariaDB, loopback only |
| Root agent | Local Unix socket only — not TCP-exposed; HMAC + peer-UID |
| Admin auth | 2FA (TOTP) enforced; login rate-limiting |
| Transport | Let's Encrypt TLS, HTTP→HTTPS, security headers, HSTS |
| Intrusion | fail2ban (sshd jail) |
| Updates | Manifest-driven, SHA-256 verified, reversible apply |
| Backups | Nightly local, checksummed; off-box encrypted backup for upgrades |
Review the architecture yourself
Alpha access includes documentation of the security model so you can evaluate it directly.