Docker — container/start

When to Use

Deploy pipeline: Start a previously created container as the second step in a create-then-start deployment workflow.
Post-reboot recovery: Restart all stopped monitoring or service containers after a host system reboot event.
Scheduled job execution: Start a pre-created job container at the scheduled time without needing to recreate it.
Blue-green cutover: Start the blue (new) container and verify it is healthy before stopping the green (old) container.
Manual recovery: Resume a container that was manually stopped for maintenance without recreating its configuration.

container/start returns immediately after instructing the daemon to start the container. It does not wait for the application inside to become healthy. Use container/inspect in a polling loop or a Delay node followed by container/inspect to verify the container reached State.Running = true.

Configuration

Connection Fields

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

Operation Fields

Field	Type	Required	Description
`resource`	string	required	Must be `container`
`operation`	string	required	Must be `start`
`ContainerId`	string	required	Container ID (full or short) or container name

Sample Configuration

{
  "resource": "container",
  "operation": "start",
  "ContainerId": "api-service-blue",
  "connection": {
    "dockerHost": "unix:///var/run/docker.sock",
    "connectionType": "unixsocket"
  }
}

Validation Errors

Error Code	Trigger	Resolution
`MISSING_INPUT`	`ContainerId` is empty or not provided	Provide the container name or ID. Use the output of `container/create` upstream: `{{ $output.containerId }}`
`NOT_FOUND`	Container does not exist	Run `container/create` first or verify the container name is correct.
`CONFLICT`	Container is already running	Check container state with `container/inspect` before calling start. Handle the CONFLICT error as a non-fatal condition if the workflow is idempotent.
`DOCKER_API_ERROR`	Docker daemon error (e.g. port already in use on host)	Check the error message. A port conflict requires stopping the other container using that port first.

Output

Success Port

Field	Type	Description
`containerId`	string	ID of the container that was started
`status`	string	`success`
`resource`	string	`container`
`operation`	string	`start`

Error Port

On failure, the error port receives errorCode, message, resource, and operation. The CONFLICT error (container already running) is typically handled as an acceptable condition in idempotent deploy workflows.

Sample Output

{
  "containerId": "a1b2c3d4e5f67890abcdef1234567890abcdef1234567890abcdef1234567890",
  "status": "success",
  "resource": "container",
  "operation": "start"
}

Expression Reference

Expression	Returns
`{{ $output.containerId }}`	Full ID of the started container — pass to subsequent inspect or exec nodes
`{{ $output.status }}`	`success` when start completed

Node Policies & GuardRails

Policy	Detail
Verify running state after start	Always follow `container/start` with a `container/inspect` check to confirm `State.Running = true` before routing traffic or removing old containers.
No remote TCP without TLS	Use `tcptls` for remote Docker hosts. Plain `tcp` is blocked in production profiles.
Handle CONFLICT gracefully	In idempotent pipelines, a `CONFLICT` error on start means the container is already running — route the error branch to a `container/inspect` to confirm and continue.
Always wire the error port	Container start can fail due to port conflicts or resource exhaustion. An unhandled error port causes silent pipeline failures.
Use named containers	Pass the container name (not just the raw ID) to `ContainerId` for readability in workflow audit logs.

Examples

Example 1: Create-then-start deploy pattern

The canonical two-step deployment: create a container with configuration, then start it, then verify health.

// Node 1: container/create
{ "Image": "myapp:{{ $trigger.version }}", "Name": "api-{{ $trigger.deployId }}" }

// Node 2: container/start — uses ID from create output
{ "ContainerId": "{{ $nodes.createContainer.output.containerId }}" }

// Node 3: container/inspect — verify it's running
{ "ContainerId": "{{ $nodes.createContainer.output.containerId }}" }
// If Condition: $output.container.State.Running === true → proceed
// Else: trigger rollback

Example 2: Restart stopped service containers after reboot

Use container/list to find exited service containers, then loop through and start each one.

// Loop node iterates over exited containers from list output
// Each iteration:
{
  "resource": "container",
  "operation": "start",
  "ContainerId": "{{ $loopItem.Names[0] }}"
}

Example 3: Blue-green start and verify

// Start blue container
{ "resource": "container", "operation": "start", "ContainerId": "api-service-blue" }

// Delay 3 seconds for process startup
// Then inspect to confirm running:
{ "resource": "container", "operation": "inspect", "ContainerId": "api-service-blue" }
// If State.Running true → exec health check → stop green container