Core concepts

Three ideas cover most of how dagweave works: the canvas, compilation, and import. This page walks through each.

The canvas

The canvas is a graph. Nodes are steps and edges are dependencies. You drag nodes out of the palette, connect them, and set each one up through a config form rather than by typing YAML.

A few things the canvas gives you beyond drawing boxes:

• Typed ports and data edges. Node inputs and outputs are typed ports, and an edge can carry data from one step’s output into the next step’s input, not just ordering. An edge that would not make sense is rejected instead of failing later at runtime. See Wiring data and nesting.
• Nested workflows. A workflow can contain another workflow, and the nested one is laid out as editable nodes rather than an opaque blob. See Wiring data and nesting.
• Guards. A node can carry a when: condition that decides whether it runs.
• Loops. A node can fan out over a list expression (withParam), a static set of items (withItems), or a numeric range (withSequence). You reference the current item as {{item}}.
• Per-node advanced settings. Resources, env, nodeSelector, retry, timeout, and a podSpecPatch escape hatch are all editable in the UI when you need them.

The graph is dagweave’s own representation, called the IR. It is defined by a JSON Schema and validated before anything compiles, so a broken graph is caught early with a clear error rather than producing bad YAML.

How it compiles to Argo Workflows YAML

Compilation turns your graph into a real Argo Workflows manifest. dagweave builds the output on Argo Workflows’ own Go types, so the result is the same structure the Argo Workflows controller expects. There is no dagweave-specific runtime and no custom fields to strip out later.

You choose what kind of object to emit in Settings:

• Workflow runs once.
• WorkflowTemplate is a reusable, named building block you submit or reference from elsewhere.
• CronWorkflow runs on a schedule.
• ClusterWorkflowTemplate is the cluster-scoped reusable building block.

Each node type compiles to one parameterised template, so shared node types stay DRY in the output. The YAML preview updates live as you edit, and you can copy it or download the file at any point. Because it is ordinary Argo Workflows YAML, kubectl apply and argo submit both work on it.

Import and round-trip

You do not have to start from a blank canvas. Import an existing Argo Workflows YAML file and dagweave lays it out as a graph automatically, with names, containers, entrypoints, and the source kind preserved.

Round-trip means import then export gives you back the same workflow, not a rewritten one. dagweave works hard to keep the export faithful:

• The source kind is preserved. A WorkflowTemplate stays a WorkflowTemplate; a CronWorkflow stays a CronWorkflow.
• Templates dagweave does not model are carried through verbatim rather than renamed or rewritten.
• Per-task arguments are kept, so a shared template still gets the right values for each task that uses it.
• Empty and injected fields are pruned, so you do not get a diff full of creationTimestamp: null and {} noise.
• generateName and global parameters survive the trip.

The point is a small, reviewable diff. You import a manifest, change one setting in the UI, export, and the git diff shows just that change instead of a wholesale reformat.

There are a couple of accepted deltas today. Comments and exact formatting are lost, because the file is parsed and regenerated rather than edited in place. Key ordering and quote style can shift for the same reason. A steps-based workflow is flattened to a dag on import. These are known and deliberate for now.

Where execution happens

dagweave is where you build workflows, never where they run. The runtime is always Argo Workflows on your own cluster. On the free path you build visually and take the YAML, then apply it to your cluster yourself. On a paid plan, a cluster operator installs the connector so dagweave can submit runs to your cluster and collect their status, logs, and artifacts; you attach triggers and watch them in the executions view. Even then, your cluster’s Argo Workflows does the running: dagweave dispatches and observes runs, it is never the execution engine. Running through the connector needs a plan that includes it.