Deployment
Self-hosted overview
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 free, unlimited servers — you pay for VMs and ops time |
TurboPanel High Availability is the default when you prefer TurboPanel to operate the panel.
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 development) |
| Daemon | turbopaneld on every managed server, including the control-plane host (co-located) |
Install path
- Control plane deployment — provision the panel (contributor dev console today; production FHS install converges via daemon Ansible roles).
- Daemon setup — enroll each server with the
turbopanel.shinstaller. - Compatibility — pair control plane and daemon channel versions before upgrades.
Not the contributor dev console
curl -fsSL dev.turbopanel.sh | sh is for contributors only. It is documented in
Local development, not as the production self-hosted path.
Pricing
Self-hosted control plane: free, unlimited servers (you provide infrastructure). See Pricing for TurboPanel High Availability (private early access).
Next steps
Edit on GitHub
Last updated on