Per-Tenant NEXUS Workspace

Each tenant runs its own NEXUS controller inside a dedicated Coder workspace. For an overview of the tenant model, see the main multi-tenancy guide.

Workspace Naming

The workspace name is openflows-nexus-{tenant}. Inside that workspace, the controller holds the Coder API token for the tenant's service account, the Redis connection, and the orchestration loop. It is the only long-lived workspace OpenFlows creates; all other workspaces are ephemeral.

# Open a shell on the tenant's NEXUS workspace to inspect logs
coder ssh openflows-nexus-my-team

tail -f /tmp/openflows-controller.log

Fault Isolation

The per-tenant NEXUS workspace is important for fault isolation. If one tenant's controller crashes or runs away with a runaway loop, it does not affect other tenants' controllers. It also makes cost attribution straightforward: the NEXUS workspace appears on the tenant's Coder usage report, and its LLM calls carry the tenant tag in the Coder AI Gateway.

Service Account Requirements

The NEXUS workspace for a tenant must be owned by a dedicated Coder service account, not by a human engineer. If a human user leaves the organization, their workspaces are typically decommissioned. A service account ensures the orchestrator keeps running.

Create a service account with a long-lived API token and store it in the orchestrator's environment under CODER_NEXUS_TOKEN.

Startup Behavior

Tenant configuration is hot-reloaded. Adding or removing a tenant does not require a global controller restart. The NEXUS workspace for the tenant starts immediately; the Redis namespace is created on first write. Existing tenants continue to operate unchanged.

Inspecting Logs

To debug tenant operations, SSH into the tenant's NEXUS workspace and check the controller logs:

# Connect to the tenant's NEXUS workspace
coder ssh openflows-nexus-{"{tenant}"}

# Watch the controller log file
tail -f /tmp/openflows-controller.log

# Or run the controller directly with verbose output
openflows --nexus --verbose