Docker — network/create

About Docker networks: Docker networks enable container-to-container communication. Containers on the same user-defined network can reach each other by container name — DNS resolution is built in. User-defined networks provide better isolation than the default bridge network.

When to Use

Application tier isolation: Create separate frontend and backend networks so web containers can only talk to API containers, which can only talk to database containers — enforcing network segmentation.
Tenant network isolation: Create a dedicated network per tenant during provisioning to guarantee that tenant containers cannot reach other tenants' containers over Docker networking.
CI environment isolation: Create an ephemeral isolated network for each CI test run to prevent cross-run interference when multiple test suites run concurrently.
Service mesh setup: Create an overlay network for distributed service communication across multiple Docker hosts in a Swarm cluster.

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
`Name`	string	required	Network name. Use a meaningful name such as `app-backend` or `tenant-0042`.
`Driver`	string	optional	Network driver: `bridge` (default, single host), `overlay` (Swarm multi-host), `host`, `none`.
`Attachable`	bool	optional	If `true`, standalone containers can attach to this overlay network.
`Labels`	string	optional	JSON key-value label pairs (e.g., `{"tenant_id":"0042","env":"prod"}`).

Sample Configuration

{
  "resource": "network",
  "operation": "create",
  "connection": {
    "dockerHost": "unix:///var/run/docker.sock",
    "connectionType": "unixsocket"
  },
  "Name": "tenant-{{ $vars.tenantId }}",
  "Driver": "bridge",
  "Labels": "{\"tenant_id\":\"{{ $vars.tenantId }}\",\"env\":\"prod\"}"
}

Validation Errors

Error Code	Condition	Resolution
`MISSING_INPUT`	`Name` field is empty.	Provide a valid network name.
`CONFLICT`	A network with this name already exists.	Use `network/list` to check existence first, or treat as idempotent and continue.
`CONFIG_ERROR`	Connection settings malformed.	Check `dockerHost` and `connectionType`.
`DOCKER_API_ERROR`	Driver not available or invalid options.	Ensure the driver plugin is installed and options are valid.

Output

Success Port

Field	Type	Description
`status`	string	`"ok"` on success.
`resource`	string	`"network"`
`operation`	string	`"create"`
`networkId`	string	The ID of the newly created network.
`networkName`	string	The network name.

Error Port

Fires when network creation fails. CONFLICT means a network with this name already exists.

Sample Output

{
  "status": "ok",
  "resource": "network",
  "operation": "create",
  "networkId": "a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2",
  "networkName": "tenant-0042"
}

Expression Reference

Expression	Returns
`{{ $output.networkId }}`	Network ID — pass to `network/connect` to attach containers.
`{{ $output.networkName }}`	Network name — include in provisioning audit log.
`{{ $output.status }}`	`"ok"` — gate downstream container creation on this value.

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 }}`.
Never use host-mode driver in production	Host-mode networks remove network namespace isolation. GuardRail blocks `Driver: "host"` in production profiles.
Apply labels for metadata tracking	Always label networks with tenant ID and environment for audit and cleanup targeting.
Always handle the error port	Wire the `CONFLICT` error port to a branch that checks whether the existing network is the correct one before continuing.
Disconnect containers before removing networks	Always disconnect all containers with `network/disconnect` before calling `network/remove`.

Examples

Example 1 — Tenant Isolation Network

Create a dedicated bridge network per tenant during onboarding. Pass the network ID to downstream container creation steps.

{
  "resource": "network",
  "operation": "create",
  "Name": "tenant-{{ $trigger.tenantId }}",
  "Driver": "bridge",
  "Labels": "{\"tenant_id\":\"{{ $trigger.tenantId }}\",\"env\":\"prod\"}"
}
// Pass networkId to container/create's Networks field

Example 2 — Application Tier Separation

Create two networks for a three-tier application: one for frontend-to-API traffic and one for API-to-database traffic. Containers are then connected to only the networks they need.

// Network 1: web tier
{ "Name": "app-web",     "Driver": "bridge" }
// Network 2: data tier
{ "Name": "app-data",    "Driver": "bridge" }

// API container gets connected to both; DB container only to app-data

Example 3 — Ephemeral CI Network

Create a uniquely named network for each CI run to prevent cross-run interference, then remove it after the test suite completes.

// Create with run-unique name:
{
  "Name": "ci-run-{{ $trigger.runId }}",
  "Driver": "bridge",
  "Labels": "{\"ci_run\":\"{{ $trigger.runId }}\"}"
}
// After tests: network/remove using the same name