Deploy on Coolify

Coolify is a good fit for putting the hub on a public server (a Hetzner or similar VPS) where NAT’d agents can dial home to it. Runaway ships a docker-compose.coolify.yml that deploys the published hub image — Coolify sources the compose file from your repo but pulls the pinned image instead of building it. The hub image is public, so the hub needs no GHCR login.

Deploy

1. Create a Docker Compose resource from the repository.

   Create a Docker Compose resource sourced from this repository (via Coolify’s GitHub App) and point it at docker-compose.coolify.yml. Coolify reads the compose file and pulls the pinned hub image.

2. Assign your domain.

   Assign your domain to the runaway service. Coolify provisions TLS and configures Traefik for you. WebSocket upgrades on /api/agent — which agents use to dial home — pass by default.

3. Deploy.

   There are no secrets to paste. RUNAWAY_MASTER_KEY, BETTER_AUTH_SECRET, and RUNAWAY_HUB_URL are filled by Coolify’s SERVICE_* magic variables. Hit deploy and the hub comes up on your domain.

Caution

After the first deploy, copy the generated RUNAWAY_MASTER_KEY out of Coolify into a password manager. It encrypts every stored GitHub token, and losing it orphans them all — see Backups and recovery.

Enroll your agents

The Coolify deploy bundles no local agent — the hub holds no Docker socket, so no runner compute lives on the public server. That’s deliberate: a hub compromise grants no Docker access on the public box. All runner compute lives on agent hosts you enroll from the hosts page. See Add more hosts to connect your first agent.

Run a single instance

SQLite is single-writer. Deploy one instance and use recreate, not rolling updates — two containers against the same data volume is unsupported.

What’s next

Enroll an agent Add the Docker hosts that run your runners.

TLS and proxies How the hub expects to sit behind a proxy.

Exposing the hub publicly What protects a public hub.