How It's Deployed
This page describes the reference deployment of OpenFlows — the standard set of pieces you stand up, and what each one is for. It's the concrete shape of the architecture in the real world.
The pieces
A full deployment has five cooperating parts:
| Piece | What it is | Role in the system |
|---|---|---|
| Coder server | The control-plane hub | Identity, model gateway, workspace provisioning, admin, audit |
| Coordination store | The shared record of truth | Holds all the team’s durable coordination state |
| Database | Coder’s own database | Coder’s internal bookkeeping |
| Controller (in the NEXUS workspace) | The brain | Runs the orchestration loop and hosts the relay |
| Worker workspaces | Disposable Coder workspaces | One agent per ticket doing the actual work |
How they're grouped
The control plane runs as a set of services together: the Coder server, the coordination store, the database, plus the Controller brain running in its long-lived NEXUS workspace.
The work plane is a ripple of short-lived workspaces (FORGE, SENTINEL, VESSEL, LORE), each one ephemeral and disposable, provisioned by the brain as needed.
Standing it up
The reference deployment starts from a clean slate:
- Run the control-plane services — the coordination store, the database, and the Coder server — configured to talk to each other. The Coder server is set up for GitHub signups and with a provisioner so it can create workspaces.
- Bootstrap — create the initial administrator, register each agent role's workspace template, and verify the model gateway and GitHub authentication are working. This also initializes the default agent team.
- Add a tenant for your repository — this creates the tenant's user and its long-lived orchestrator workspace, bound to the GitHub repo.
- Complete GitHub OAuth for that tenant — the scoped identity OpenFlows uses to act on GitHub.
- Configure notifications (optional) — Slack, Discord, or WhatsApp for human escalations.
- Open an issue — and run the pipeline.
Self-sufficiency of the deployed system
Once it's up, the deployment mostly runs itself:
- The Controller self-heals: a bad pass is logged and retried, never fatal.
- Liveness beacons let the brain detect silent workspaces and recover them.
- Workspaces tear down after their work merges, keeping the fleet from accumulating cruft.
- A doctor command diagnoses the Coder integration when something looks off.
Operated via the control panel
Day-to-day operation — status, the agent registry, pause/target/continue, human escalations, GitHub OAuth linking — happens through the web control panel (with a command-line surface that stays in sync). The panel rides on the same state and commands as the command line, so they can never disagree.
Running many teams
Because the deployment is multi-tenant by design, one Coder server and one coordination store can serve many independent teams, each isolated — you just add each team as its own tenant.