Run on your cluster
dagweave never runs your workflows itself. Your own cluster’s Argo Workflows is always the runtime. dagweave submits runs to it and shows you the results: status, logs, metrics, and artifacts. This is the paid path. The free path is to build a workflow and take the YAML, which you apply yourself.
Two roles
Section titled “Two roles”Connecting a cluster is a one-time job for one person. A cluster operator installs the connector once per cluster and turns on the features you want. After that, workflow authors run workflows from dagweave without touching Kubernetes.
More than one cluster
Section titled “More than one cluster”You can connect more than one cluster. Install one connector in each. dagweave aggregates across all of them, and when you run a workflow or attach a trigger you choose which cluster and namespace it targets.
Teams run several clusters for real reasons:
- Staging and production. Connect a test cluster and a production cluster, and promote the same workflow from one to the other.
- Scale, region, or isolation. Split work across clusters by capacity, by region, or to keep tenants apart.
Two facts to keep straight. One connector serves one cluster; a single connector
does not route across clusters. Within a cluster, Argo Workflows is often
installed per namespace, so one cluster can host several Argo Workflows
instances. You model each instance as an ArgoConnection, which the operator
writes after installing the chart. The chart itself creates none, and the
connector refuses to dispatch to a target no ArgoConnection matches.
Where to go next
Section titled “Where to go next”- Installing the connector sets up a cluster.
- Triggers decide when a workflow runs: manual, cron, webhook, GitHub, or AWS SNS.
- Executions show each run with its logs, metrics, and a re-run button.
- The run timeline splits each step’s wall clock into the time it queued and the time it worked.
- Runs you did not start covers the Argo runs already on your cluster, which dagweave stores and lists apart from the ones it dispatched.
- Why a run is not moving tells a lock wait from an unschedulable pod.
- Test with real data runs a workflow against a real Postgres row or S3 object from a connected source.