Self-hosted overview

Private alpha — not yet publicly available

Self-hosted TurboPanel is in private alpha, alongside TurboPanel High Availability. Neither is publicly available yet — this page documents where we are headed as we work toward a beta release. Expect breaking changes before then. See the roadmap for progress.

Self-hosted TurboPanel delivers the same product as TurboPanel High Availability. You operate the control plane — uptime, upgrades, backups, and public access are your responsibility. Workload servers and daemons remain yours.

When to choose self-hosted

You want…	Self-hosted fits when…
Full operational custody	Your team runs the control plane stack (Deno, Postgres, Caddy, UI export)
Data residency you control	Panel data stays on infrastructure you provision
Predictable infra cost	Control plane is planned to be free, unlimited servers — you pay for VMs and ops time

TurboPanel High Availability is the planned default when you prefer TurboPanel to operate the panel. Both paths are in private alpha and not yet publicly available.

What you run

Component	Role
Control plane	Hono API on Deno (Unix socket) + Postgres + Caddy TLS
UI	Static export at `/opt/turbopanel/share/ui` (or Expo dev proxy during contributor development)
Daemon	`turbopaneld` on every managed server, including the control-plane host (co-located)
Managed DB ingress	Per-server ProxySQL on 5432 / 3306 — architecture

Install path (preview)

When self-hosted is publicly available, operators follow this sequence:

Control plane deployment — provision the panel on Debian or Ubuntu (planned managed FHS install via daemon Ansible roles; private alpha preview).

Complete the install wizard (host PAM + superadmin) and trust the platform CA from GET /api/daemon/v1/instance/ca.

Daemon setup — enroll each server with the turbopanel.sh installer and an organization license.

Compatibility — pair control plane and daemon channel versions before upgrades.

When you run managed databases, hosts that serve SQL clients also converge ProxySQL. Trust the org CA for verify-full client TLS and firewall listeners plus private / TurboFabric paths as described in Managed database ingress and Security.

Compose projects: compiled runtime file

When you deploy a Docker Compose project from the panel, TurboPanel stores a project base compose and an environment overlay, then compiles them into a single compose.yaml the daemon runs:

docker compose -p <project-id> -f compose.yaml

Layer merge follows the Compose Spec merge rules: mapping keys merge recursively (later layers win per key), most sequences (ports, volumes, env_file, …) append with key-based de-duplication, and command / entrypoint / healthcheck.test fully replace. Use !reset to delete a key on the overlay and !override to force full replacement instead of append/merge.

The console Merged compose preview is a readability aid; Prepared compose and the real deploy path use that compiled compose.yaml. Operator detail: Control plane — Compose deploys. Architecture: API — compiled compose.

Contributors only — Vagrant workflow

Contributor development uses Vagrant and sibling checkouts — not a production self-hosted install. See Local development.

Pricing

Self-hosted control plane: planned to be free, unlimited servers (you provide infrastructure) once it is publicly available. TurboPanel High Availability status and waitlist: Pricing. Both paths are currently in private alpha.

Next steps

Deployment hub — Operator overview
Upgrade & rollback
Uninstall & data export
Daemon trust model
Open source
Licensing — Repository licenses, notices, and Corresponding Source