Installation
TurboPanel is split across multiple repositories. Installation paths depend on whether you are setting up contributor local dev, a self-hosted control plane, or an additional managed server daemon.
Contributor local development
Bootstrap the dev console from dev:
curl -fsSL dev.turbopanel.sh | shThe one-liner clones or updates ~/dev (or ${TURBOPANEL_DEV_ROOT}/dev) and launches ./console automatically. ./console installs the pinned Node runtime (sudo on first run), runs pnpm install, and starts the Ink dev console. From the console, use Start dev stack to install the daemon, bootstrap orchestration, and bring up instance + Caddy + UI via systemd. To run the console again later: cd ~/dev && ./console.
See Local development for console areas, URLs, and day-to-day workflow.
Self-hosted control plane (Debian / Ubuntu VM)
Control plane install path
Self-hosted control planes use the dev console on a VM (Start dev stack). Additional managed server daemons use the public installer documented below.
On a fresh Debian or Ubuntu host:
curl -fsSL dev.turbopanel.sh | shIn the console, choose Start dev stack. This writes developer identity into /etc/turbopanel/daemon.env, bootstraps the daemon orchestration runtime, enables co-located dev mode (TURBOPANEL_DEV_INSTANCE=1), installs turbopaneld.service, and tails journals. The daemon then runs Ansible to install instance (Deno), Caddy, UI, and Postgres: source repos under $HOME (~/daemon, ~/instance, ~/ui, ~/website), mutable state under dev-user-owned FHS paths (/etc/turbopanel, /var/lib/turbopanel, /var/log/turbopanel, /run/turbopanel), and vendored runtimes under /opt/turbopanel/vendor.
- HTTPS entrypoint:
https://<host>:8443(Caddy) - Install wizard: first visit prompts host PAM + superadmin setup (Deno path)
- Trust the platform CA from
GET /api/daemon/v1/instance/caor~/instance/certs/ca.crt
Details: Control plane.
TurboPanel High Availability
The instance can run on Cloudflare Workers (pnpm deploy in the instance repo; requires TURBOPANEL_DATABASE_URL for migrations and CLOUDFLARE_ENV, e.g. live or testing, matching wrangler.jsonc). Hosted daemon coordination uses Durable Objects — remote daemons connect over HTTPS/WSS to a reachable instance URL. See Control plane.
Additional managed server daemons
Install the daemon on servers that should be managed remotely (not the co-located control plane). Obtain a license from your organization first.
TurboPanel High Availability (Cloudflare Workers):
curl -fsSL turbopanel.sh | TURBOPANEL_LICENSE=<base64url-encoded-license> shSelf-hosted instance (pass TURBOPANEL_HOST):
curl -fsSL turbopanel.sh | \
TURBOPANEL_LICENSE=<base64url-encoded-license> \
TURBOPANEL_HOST=https://<instance-host>:8443 \
shThe installer self-escalates with sudo and prompts for your password when
needed — do not prefix the pipeline with sudo.
Replace host and port with where the instance is reachable from the node. The
installer fetches the platform CA from /api/daemon/v1/instance/ca automatically
for HTTPS instances.
Supported platforms (managed nodes)
| OS | Architecture |
|---|---|
| Debian 12+ | x86_64 (amd64), aarch64 (arm64) |
| Raspberry Pi OS 64-bit | aarch64 (arm64) only |
32-bit ARM (including 32-bit Raspberry Pi OS) is not supported.
Full options and examples: Daemon setup.
Prerequisites (all paths)
- 64-bit Linux server (Debian 12+ recommended for Ansible paths; Raspberry Pi OS 64-bit on arm64)
- Docker (optional — installed on demand when a node runs container workloads)
- SSH access to GitHub for platform repo clones on co-located dev hosts (
git@github.com:turbopanel/...) - For local dev: see Prerequisites
Next steps
- Control plane — Components, configuration, and API surface
- Daemon setup — Node installer flags and communication
- Security — TLS, socket access, and hardening
Last updated on