DB Network Isolation

ROBOCO_DB_NETWORK_ISOLATED is different from every other flag on this page: it isn't something you flip at runtime, and it isn't in the panel's Feature Flags card. It's a compose-topology setting — it must travel with a specific networks: layout, because a runtime toggle can't change which Docker network a container joined at boot.

Not a panel toggle

This flag only means something paired with the matching compose topology below. There's nothing to flip in Settings → Feature Flags for it — it's an environment/compose setting.

What it does

All three tracked compose files (docker-compose.yml, docker-compose.yaml, docker-compose.registry.yml) ship two user-defined bridge networks instead of one:

  • roboco_data carries only Postgres and Redis.
  • roboco_default carries everything else: the panel, nginx, Ollama, every spawned agent container, and their sandbox DB/Redis sidecars.
  • The orchestrator is the only multi-homed service — it joins both networks, since it's the one process that legitimately needs to reach the production database directly.

The practical effect: agent containers cannot resolve or TCP-reach roboco-postgres:5432 or roboco-redis:6379 at all. Since Redis has no auth of its own, network membership is its entire containment. Nothing else changes — agent↔agent A2A traffic, orchestrator→agent SDK polls, MCP→orchestrator calls, and the published host ports (15432 / 16379 / 11435) are all unaffected, as is anything that rides the Docker daemon socket (docker exec/inspect).

It suppresses the legacy prod-creds injection

When this flag is true, the orchestrator's legacy _append_gate_env step (which — only when toolchain matching is also on — hands an agent RoboCo's own database credentials so its test gate can run against a real Postgres) is suppressed entirely. Handing out credentials for a host the agent can't reach anyway is worse than handing out none — the connection would just dead-end in a timeout instead of failing cleanly. A project that needs a real database for its gate should opt into the sandboxed dev DB/Redis/Mongo instead.

Default state

Unlike the other four features on this page, this one ships armed in every tracked compose file, including the registry compose — it's the only optional flag that is. You'd only see the old shared-network behavior by hand-editing the compose networks section yourself (not recommended).

VariableDefault (config)Default (all 3 tracked composes)
ROBOCO_DB_NETWORK_ISOLATEDfalsetrue

Next

Sandboxed dev DB/Redis/Mongo — what an opted-in project uses instead of direct database access. → Security — the full trust model this topology is part of. → back to Optional subsystems.

llms.txt