Self-hosting overview
Why self-host the dFlow control plane, core Compose components, and links to install guides.
Written By Zoro
Last updated 3 days ago
Self-hosting
Self-hosting means you run the dFlow control plane (dashboard, API, and related services) on your infrastructure, typically with Docker Compose as in the repository root docker-compose.yml. You still use Worker Nodes for application Services; those can be the same cluster or separate machines.
Operator responsibilities vs application team
If your org splits roles, hand this section to whoever owns the Linux hosts and Compose files. Everyone else should start with How dFlow is structured under Core Concepts in the sidebar and Quick start for Self-Hosted dFlow under Getting Started in the sidebar.
Why self-host
- Data and control-plane residency; keep metadata and UI inside your network when policy requires it.
- Custom networking; integrate Tailscale, private DNS, and internal-only endpoints; Tailscale and networking.
- Avoid cloud control-plane fees; trade vendor hosting for your own ops effort.
- Flexibility; deploy on your chosen Linux host or VM provider.
Core components (reference stack)
The published docker-compose.yml commonly includes:
Exact services and image tags can change by release; always prefer your checked-in file.
Requirements snapshot
- Docker 20.10+ and Compose v2+ on a Linux host
- Ports 80 and 443 open for HTTP(S) when serving the UI and proxy
- Environment variables for MongoDB, Redis, Tailscale (if used), email, and public URLs; see
DOCKER.mdand Environment configuration
For sizing, read System requirements.
Next steps
- Installation options
- Install with Docker / Docker Compose
- Quick start for Self-Hosted dFlow (first Organisation, Worker Node, Application)
- How dFlow is structured and Platform architecture