Skip to content
Containly

Automate with workflows

Workflows (Pro, Containly 2.7.0) react to unhealthy containers, offline hosts, finished backups or a schedule with safe, predefined steps. Templates, drafts, scope, simulate, run now, circuit breaker and history explained.

Since Containly 2.7.0 the Workflows page automates routine reactions. A workflow is a rule: when something happens (the trigger), Containly checks a few conditions and then runs predefined steps, with an optional otherwise branch when the conditions are not met. There is no scripting and no free-form command: triggers, conditions and steps are a fixed list, and every action is written to the audit log.

Workflows are a Pro feature. On Free the page shows the templates as a read-only preview with an upgrade hint. If a Pro licence ends, existing workflows pause with the reason "licence" and resume on their own once Pro is active again. Only admins create, edit, enable or run workflows; viewers can read them.

What a workflow can do

PartChoices
TriggersContainer becomes unhealthy, container exits unexpectedly (optionally only when killed for lack of memory, OOM), container restarts in a loop, host goes offline, host is back online, CPU stays high, memory stays high, backup finished (failed, succeeded or any result), schedule (hourly, chosen weekdays or monthly)
ConditionsCPU or memory above or below a value, how long the state has lasted, how fresh the data is, host reachable, backup target reachable, not held by a running backup or restore
StepsNotify, restart container, start container, stop container, run backup plan, update container, wait until healthy, wait

Conditions are combined with all or any. A value Containly does not know counts as "not met", so nothing changes on stale data. Containly checks container and host states once a minute and schedules every 30 seconds, so a trigger like "lasts at least 2 minutes" has minute resolution.

Start from a template

Open Workflows in the navigation. Below My workflows you find Templates: 20 ready workflows in six groups. Every group starts closed; click a group header (or use the keyboard) to open it. Only one group is open at a time, opening another one closes the previous one.

GroupTemplates
Health and recoveryUnhealthy container: notify and restart; Unhealthy container: notify only; Crashed container: notify and restart; Restart loop: critical alert
BackupsBackup failed: alert; Backup succeeded: short notice; Nightly backup when host and target are ready; Weekly backup with a report
UpdatesWeekly: backup first, then update; Weekly update only when everything is ready; Monthly: backup, update and health check
HostsHost offline: alert; Host back online: notice
CPU and memorySustained CPU: notify; Sustained memory: notify; CPU stuck high: notify and restart; Memory leak: notify and restart
Schedules and maintenanceWeekly restart; Stop every night; Start every morning

Open a template and click Save as draft, or click New workflow and Create draft to start empty. Your own workflows are listed under My workflows with their state (Draft, Enabled, Paused).

Pick what the workflow may touch

Every workflow has a scope (Applies to): containers, stacks, hosts and backup plans. Templates start with an empty scope, so nothing runs until you pick something.

  • Changing steps (restart, start, stop, update) only ever act on containers you picked, by name or as part of a picked stack. They never act on a whole host.
  • Hosts are enough for alerts: a workflow scoped to a host watches every container on it, but only notifies.
  • Backup plans are needed for the backup trigger, the backup step and the "backup target reachable" condition.

Containers are matched by name per host, so a recreated container stays in scope; renaming a container takes it out. The same container name on another host is a separate resource.

A workflow with gaps is marked Needs a fix in the builder (for example a restart step without a picked container). You can save it as a draft, but you cannot enable or run it until the builder shows no problems.

Enable, simulate and run now

New workflows start as drafts and do nothing. Set the state to Enabled when the builder shows no problems; Paused stops it again without deleting it.

The Simulate tab is a dry run: it checks the conditions against the live state and shows which steps would run. Nothing is changed and no notification is sent; the run appears in the history as "Simulation".

Run now executes the real steps once, also for a draft, with every safety check (scope, circuit breaker, host reachable, backup before update). Only the cooldown is skipped. Use it to test a workflow on purpose.

Safety: cooldown, circuit breaker and backup before update

  • Cooldown: after a run, the same workflow waits this long (in minutes) before it acts on the same resource again. While a problem lasts, a state trigger fires again after each cooldown; cooldown 0 means once per incident.
  • Circuit breaker: by default at most three changing actions per 60 minutes and resource. When the limit is reached the breaker opens: no more actions on that resource and one alert. The workflow then shows Breaker open in the list; open it and click Re-arm after you have looked at the cause.
  • Backup before update: an update step only runs after a backup step earlier in the same run that finished successfully. A failed backup, or one with warnings, blocks the update and the history says why. The update pulls the newest image for the container's tag and recreates only that container; Containly never updates itself through a workflow.
  • Always on: locked or offline hosts are skipped, a resource held by a backup or restore is left alone, at most three runs happen at the same time, and a workflow's own actions never trigger another workflow.

Cooldowns, breakers and the run history are stored in the database, so they survive a restart of Containly.

Notifications, history and audit log

The Notify step sends an in-app notification, an e-mail or both. Recipients are set under Settings > Notifications > Workflow notifications (category Automation); e-mail needs SMTP to be set up. Since Containly 2.7.1 the step can also send to saved notification channels (ntfy, Gotify or a webhook), see Notification channels. Since Containly 2.7.2 it can also use Discord, Telegram, Slack and Pushover channels and Push to devices (web push to the recipients' devices), see Push notifications and Discord, Telegram, Slack, Pushover.

The History tab lists every run with its trigger, the result of each condition and each step (for example "Backup finished with warnings. That is not enough for an update."). Runs are kept for 90 days. Every action of a workflow is also in the audit log, with "Workflow: <name>" as the user.