Installation

This page describes what running OpenFlows requires and how a production environment is put together. The goal is to give you the full picture before you start, so you can plan your deployment.

1What you need before you start

OpenFlows is not a standalone tool - it is a system that orchestrates a fleet of workspaces. To run it, you need:

• A Coder server (self-hosted). This is the control plane that provides identity, model access, and the disposable workspaces where agents run.
• GitHub integration. OpenFlows turns GitHub issues into pull requests, so it needs a repository and GitHub authentication for it.
• A coordination store. OpenFlows uses a shared record of truth to coordinate the team.
• A database for the Coder server itself.

If you do not already operate Coder, the reference deployment stands up Coder, the coordination store, and the database together, so you can start from a clean slate.

2The high-level topology

The system is split into a control plane and a set of worker workspaces.

The control plane is where the intelligence lives. It holds the Coder server (identity, the model gateway, and workspace management), the long-lived orchestrator that runs the coordination loop, the coordination store, and Coder's database. This is the only place that legitimately holds credentials.

The worker workspaces are ephemeral and disposable - one per agent role per ticket. They hold no model keys, no raw repository credentials, and no secrets. They have tight network access because the intelligence and credentials they need live centrally, in the control plane, rather than inside them.

The core idea that makes this safe is that Coder governs where agents run and OpenFlows governs how they coordinate. See the Coder Integration page for more on this split.

3The reference deployment

The simplest supported path stands up the whole control plane as a set of containers:

• Coordination store - configured for durable storage so facts survive restarts.
• Database - Coder's database.
• Coder server - configured with the database, your access URL, a provisioner, and GitHub signups enabled.

You then run the OpenFlows installer against this environment to set up the initial state.

4What the installer does

After the control plane is standing, you complete a bootstrap sequence:

1. Bootstrap the environment - create the initial administrator, register the workspace templates each agent role uses, and verify that both the model integration and GitHub authentication are reachable. This also initializes the default agent team in the control plane.
2. Add a tenant for a repository - this creates the tenant and its long-lived orchestrator workspace, bound to a specific GitHub repository.
3. Complete GitHub OAuth for that tenant - the mechanism OpenFlows uses to act on GitHub on behalf of a real identity, rather than a shared credential.
4. Configure notifications (optional) - wire up Slack, Discord, or WhatsApp so OpenFlows can reach you when a human decision is needed.
5. Open an issue - and watch the team turn it into a reviewed, merged pull request.

5Manageable at runtime

OpenFlows ships a control panel (a web interface) plus a command-line surface that stay in sync. From either, you can:

• See the live status of tickets, workers, and pull requests.
• Edit the agent registry (roles, models, skills) with no restart.
• Pause, drain, or target the fleet toward specific work.
• Attend to human escalations and link GitHub OAuth.

Installation is a one-time setup; from then on, day-to-day control happens through the panel.

Reference