Docker — container/restart

When to Use

Health-check recovery: Restart an unresponsive container detected by a monitoring workflow — faster than a stop-then-start sequence and preserves container configuration.
Memory leak remediation: Cycle an application that leaks memory over time to release heap and restore performance without redeployment.
Post-dependency recovery: Restart an application container after its upstream database or message broker recovers from downtime, to refresh connection pools.
Config change application: Some configuration changes (e.g. mounted file changes) require a restart to take effect — use container/restart as part of the config update workflow.
Scheduled container refresh: Periodically restart long-running containers as a precautionary maintenance measure during low-traffic windows.

Restart reuses the original container configuration. It does not pull a new image or apply new environment variables. If you need to update image or environment, use the create-stop-remove-create-start pattern instead.

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	Grace period for shutdown before SIGKILL. optional

Operation Fields

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

Sample Configuration

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

Validation Errors

Error Code	Trigger	Resolution
`MISSING_INPUT`	`ContainerId` is empty	Provide the container name or ID.
`NOT_FOUND`	Container does not exist	Verify the container name. If the container was removed, recreate it with `container/create`.
`DOCKER_API_ERROR`	Daemon error during restart	Check daemon logs. Possible causes: OOM kill during shutdown, volume unmount failure.

Output

Success Port

Field	Type	Description
`containerId`	string	ID of the restarted container
`status`	string	`success`
`resource`	string	`container`
`operation`	string	`restart`

Error Port

On failure, the error port receives errorCode, message, resource, and operation. After a restart failure on a critical service, trigger an alerting node immediately.

Sample Output

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

Expression Reference

Expression	Returns
`{{ $output.containerId }}`	ID of the restarted container — pass to `container/inspect` for health verification
`{{ $output.status }}`	`success` when restart completed

Node Policies & GuardRails

Policy	Detail
Verify running state after restart	Follow `container/restart` with `container/inspect` and check `State.Running = true`. The daemon may report success even if the container exits immediately after start.
Restart does not update image	Never use restart as a deployment mechanism. Always use the full create-stop-remove-create-start sequence when updating image versions.
Limit automated restart chains	Workflows that restart containers in response to health failures must include a cooldown or retry limit to prevent restart storms.
No remote TCP without TLS	Use `tcptls` for remote Docker hosts.
Alert on restart failure	A failed restart of a critical container requires immediate human escalation. Always connect the error port to an alerting node for production services.

Examples

Example 1: Health-check recovery automation

A monitoring workflow detects a container that is running but not responding to health pings. Restart it and verify recovery.

// Trigger: health check HTTP call returns non-200
// Node 1: container/restart
{ "resource": "container", "operation": "restart", "ContainerId": "{{ $trigger.containerName }}" }

// Node 2: Delay 5 seconds
// Node 3: container/inspect
{ "resource": "container", "operation": "inspect", "ContainerId": "{{ $trigger.containerName }}" }

// Node 4: If Condition
// State.Running === true → notify "container recovered"
// State.Running === false → escalate incident

Example 2: Nightly memory-leak mitigation

// Scheduled trigger: every day at 3:00 AM
{
  "resource": "container",
  "operation": "restart",
  "ContainerId": "report-generator",
  "connection": { "timeoutSeconds": 30 }
}
// Send Slack notification: "report-generator restarted at 3 AM for maintenance"

Example 3: Post-dependency restart sequence

// Triggered when database container restarts (via webhook or event trigger)
// Restart application containers that connect to the database:
[
  { "resource": "container", "operation": "restart", "ContainerId": "api-service" },
  { "resource": "container", "operation": "restart", "ContainerId": "worker-service" },
  { "resource": "container", "operation": "restart", "ContainerId": "scheduler-service" }
]
// Run in parallel using ParallelFork node for faster recovery