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 hub straight from the repository — Coolify clones the repo and builds the hub image on your own server, so there’s no prebuilt image and no GHCR login for the hub.

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 clones the repo and builds the hub’s runtime Dockerfile stage on the server.

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 BETTER_AUTH_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.