Run a workflow

dagweave run my-workflow.yaml

takes either a dagweave canvas file or plain Argo Workflows YAML, and runs it on this machine. dagweave lint my-workflow.yaml checks the same file without running it: see What it will refuse, and why.

Two tiers, chosen for you

A workflow made only of script and plain-command steps runs directly on the host: nothing to install, nothing to boot. Anything that wants a container image, sidecars, init containers, volumes, artifacts, or a daemon gets a real single-node Kubernetes cluster instead, started once and hidden behind the run.

You never choose the tier. It comes off the workflow itself, and the run tells you which template made that choice:

$ dagweave run examples/pipeline.yaml
dagweave: running on the host, because every step is a command this machine can run directly
dagweave: steps run against this machine, so alpine:3.20 is not used
dagweave: steps share this machine's /tmp, which separate pods would not, so a step reading what another wrote there works here and would not on a cluster
hello
HELLO
5
HELLO has 5 letters

  Succeeded  pipeline-.produce        4ms
  Succeeded  pipeline-.shout          6ms
  Succeeded  pipeline-.count          6ms
  Succeeded  pipeline-.finish         3ms
  Succeeded  pipeline-                14ms

dagweave: Succeeded, 5 step(s), under ~/.local/state/dagweave/runs/pipeline

That is a four-step DAG with parameters passed between steps and two branches running in parallel, finished in milliseconds, with no Docker and no Kubernetes involved. The lines before the table are the steps’ own output, since one step’s stdout is what the next step reads. The last row is the DAG itself, which is why the count says five rather than four.

The split exists because of the arithmetic: removing Kubernetes from a run saves about 22 seconds once, and rebuilding a container image costs 30 to 90 seconds on every edit. The fast path has to need neither.

The first run that needs the cluster tier takes longer, 20 to 90 seconds or so, because it boots a real single-node cluster first. That cluster stays up after the run finishes, so the next cluster-tier run pays no boot at all. Nothing prunes it automatically; see Housekeeping.

Your own canvas, not just Argo YAML

A workflow saved from the dagweave canvas runs here as the file the editor saved, not as YAML you had to export first. run and lint both compile it with dagweave’s own compiler, so what runs on your machine is the same graph the cluster would run, rather than a second reading of it. A canvas saved as a WorkflowTemplate runs too: asking to run one asks for a Workflow, the same thing the run button in this app does with it.

What it does not pretend

A step that names a container image but runs on the host tier is running against your machine’s own shell, not that image, and the run says so, every time, rather than staying quiet about it. Nothing here caps a step’s CPU either: a step gets every core it can see, on either tier, because that is what an unconstrained step would get on a real cluster too. Write a cpu limit into the workflow if you want one enforced; the cluster tier’s own kubelet honours it the way a real one would.