Self-hosting overview
What a self-hosted installation consists of, the three ways to run it, and what it never does — no license checks, telemetry or limits.
Self-hosted
A self-hosted control plane is the API, the web dashboard, MongoDB and (optionally) Redis. Workers run natively on developer machines and connect outbound to it, so those machines need no inbound ports.
What a self-hosted installation never does
- No calls to vendor infrastructure: no license checks, no telemetry, no marketplace.
- No limits on tasks, workers, projects, members or execution time.
- Private capabilities, prompts and code stay on your infrastructure.
Outbound features — push notifications, telemetry, error tracking — are off until you configure them.
Ways to run it
| Option | For | Page |
|---|---|---|
| Docker Compose | One machine; the quickest path; production with Caddy and automatic HTTPS | Docker |
| Kubernetes (Helm, Terraform) | Several replicas, autoscaling, scheduled backups, Prometheus alerts | Kubernetes |
| Node.js directly | Your own service manager and reverse proxy | Docker |
Checklist before others use it
- Set
PUBLIC_URL,WEB_URLandCORS_ORIGINSto the real address, behind TLS (SSL). - Back up MongoDB and
ENCRYPTION_KEY(Backups). - After creating the first account, set
ALLOW_REGISTRATION=falseand invite members. - Configure SMTP so invitations and alerts are emailed (Configuration).
- Set
REDIS_URLif you run more than one API instance (Redis).