Architecture

This section explains how the OpenFlows system is put together - in plain language, with no code. It's written for anyone who wants to understand the system well enough to operate it, extend it, or evaluate its security.

OpenFlows Manager owns product identity, repository connections, runtime authorization, credential brokerage, and durable workspace operations. Coder runs isolated workspaces. A tenant's Nexus controller coordinates agents using tenant-scoped Redis and an A2A relay.

Recommended reading order

1. Components and Interactions: identify the independently running parts and trust boundaries.
2. Manager Runtime: follow registration and durable provisioning.
3. Credentials and Trust: see which token authorizes each connection.
4. Hooks and A2A: distinguish lifecycle delivery from tenant-local agent communication.

The pages below continue with the controller, worker fleet, recovery, security, and deployment. If you are new to the product, begin with the full documentation reading path.

The centre of the picture

Nexus requests workers through the Manager runtime API. Manager checks the tenant, role, quota, and pinned template, records a durable operation, and calls Coder to create the workspace. Forge, Sentinel, Vessel, and Lore run inside those workspaces. Nexus never needs the platform Coder operator credential.

The architecture is built on a simple thesis: architecture is the product. OpenFlows encodes the engineering - the review gates, the recovery patterns, the trusted boundaries - so that agents produce software, not just code. The guardrails that run through the whole design are straightforward: plan before code, when in doubt, don't approve, and bounded recovery then human escalation. Workspaces receive scoped runtime and Redis credentials; platform signing keys remain in Manager.