Background Execution

Use background mode when a workstation or VPS is not already supervised by systemd, Docker, or Kubernetes.

woml run workflows/ --background

The parent command waits for genuine readiness before it returns. This matters: a process ID alone does not prove that the state database opened, ports bound, providers authenticated, and triggers became ready. If startup fails, WOML reports the runtime log path instead of pretending that automation is active.

Follow the detached runtime

You can leave and later follow one workflow or run without restarting anything:

woml orders --logs
woml run_8f21c4 --logs

Ctrl+C exits the log viewer. It does not stop the background runtime.

Use the live inspector for the entire state boundary:

woml inspect

Stop it deliberately

Stop the runtime that owns the selected state boundary:

woml stop
woml stop --state ./data/workflow-history.sqlite

stop contacts the authenticated local runtime, closes trigger admission, allows graceful shutdown work, and then ends the process. Selecting the wrong --state path addresses a different runtime authority, so use the same path you used with run.

When not to use background mode

Do not combine --background with Docker, systemd, Kubernetes, or another supervisor. Those systems already provide restart policies, logs, health checks, and process lifetime. Detaching inside them hides the process they are supposed to supervise.

Background and foreground modes use the same Rust engine and durable semantics. Background mode is convenience, not a weaker alternate executor.