Docker — network/connect

Hot-plug networking: network/connect attaches a container to a network while it continues running — no restart required. The container immediately gains DNS resolution and IP connectivity on the target network.

When to Use

Post-health-check wiring: After a newly deployed container passes its health check, connect it to the application network so traffic can flow to it — preventing premature exposure of unhealthy containers.
Monitoring container multi-homing: Connect a monitoring container (e.g., Prometheus exporter) to multiple application networks so it can scrape metrics from containers on each network.
Sidecar attachment: Attach a sidecar container to the same network as its primary container after both are started, enabling inter-process communication.
Live reconfiguration: Add a container to a new network segment during a maintenance window without taking it offline.

Configuration

Connection

Field	Type	Default	Description
`dockerHost`	string	`unix:///var/run/docker.sock`	Docker daemon socket path or TCP endpoint.
`connectionType`	string	`unixsocket`	One of: `unixsocket`, `tcp`, `tcptls`.
`tlsCertPath`	string	—	TLS certificate directory. Required for `tcptls`. optional
`timeoutSeconds`	int	30	Operation timeout. optional

Operation Fields

Field	Type	Badge	Description
`NetworkId`	string	required	Network ID or network name to connect the container to.
`ContainerId`	string	required	Container ID or container name to connect.

Sample Configuration

{
  "resource": "network",
  "operation": "connect",
  "connection": {
    "dockerHost": "unix:///var/run/docker.sock",
    "connectionType": "unixsocket"
  },
  "NetworkId": "app-backend",
  "ContainerId": "api-server"
}

Validation Errors

Error Code	Condition	Resolution
`MISSING_INPUT`	`NetworkId` or `ContainerId` is empty.	Provide both network and container references.
`NOT_FOUND`	Network or container does not exist.	Verify both names/IDs. Use `network/list` and `container/list` to confirm.
`CONFLICT`	Container is already connected to this network.	Treat as idempotent — the container already has connectivity.
`CONFIG_ERROR`	Connection settings malformed.	Check `dockerHost` and `connectionType`.
`DOCKER_API_ERROR`	Unexpected daemon error (e.g., IP address pool exhausted).	Check subnet capacity with `network/inspect`.

Output

Success Port

Field	Type	Description
`status`	string	`"ok"` when the container is connected successfully.
`resource`	string	`"network"`
`operation`	string	`"connect"`
`networkId`	string	The network that was connected to.
`containerId`	string	The container that was connected.

Error Port

Fires when connection fails. Output contains status: "error", errorCode, and errorMessage.

Sample Output

{
  "status": "ok",
  "resource": "network",
  "operation": "connect",
  "networkId": "app-backend",
  "containerId": "api-server"
}

Expression Reference

Expression	Returns
`{{ $output.status }}`	`"ok"` — gate traffic routing on this value.
`{{ $output.networkId }}`	Network the container was connected to.
`{{ $output.containerId }}`	Container that was connected — include in deployment audit log.

Node Policies & GuardRails

Policy	Enforcement
Never expose Docker daemon TCP without TLS	Use `tcptls` for remote connections. Plain `tcp` is blocked in production GuardRail profiles.
Store TLS certificates in Credentials Manager	Reference `tlsCertPath` via `{{ $credentials.dockerTlsCertPath }}`.
Gate network connection on health check	Only connect containers to production networks after health checks confirm readiness. Never connect containers that failed startup validation.
Never interpolate user input into NetworkId or ContainerId	Network and container references must come from trusted workflow variables.
Always handle the error port	Wire the error port to alerting nodes — connection failures block inter-service communication.
Restrict container/exec to approved commands	Arbitrary exec access is root-equivalent. GuardRail exec policies restrict allowed command prefixes.

Examples

Example 1 — Post-Health-Check Network Join

Start a new container, wait for its health check to pass, then connect it to the production network so live traffic can reach it.

// Step 1 — container/start
// Step 2 — container/inspect (poll until State.Health.Status === "healthy")
// Step 3 — network/connect
{
  "resource": "network",
  "operation": "connect",
  "NetworkId": "app-backend",
  "ContainerId": "{{ $node['container-start'].output.containerId }}"
}

Example 2 — Attach Monitoring Sidecar to Multiple Networks

Connect a Prometheus exporter container to all application networks so it can scrape metrics from containers on each network segment.

// Loop over target networks:
{
  "resource": "network",
  "operation": "connect",
  "NetworkId": "{{ $loopItem.networkName }}",
  "ContainerId": "prometheus-exporter"
}
// Networks: ["app-frontend", "app-backend", "app-data"]

Example 3 — Blue-Green Cut-Over

In a blue-green deploy, connect the new (green) container to the load-balancer network once it is healthy, then disconnect the old (blue) container.

// Step 1: Connect green to lb network
{ "NetworkId": "lb-network", "ContainerId": "app-green" }

// Step 2: Disconnect blue from lb network
{ "resource": "network", "operation": "disconnect",
  "NetworkId": "lb-network", "ContainerId": "app-blue" }