Skip to content
Git

Your workflows stay in your own repo.

dagweave writes a standard Argo Workflows manifest to the repo and path you pick. Your cluster runs that same file.

The problem

Why platform teams skip visual builders.

Most visual builders store the workflow in their own database, behind an export button. Platform teams keep writing YAML by hand instead.

What you own

The file is yours from the first commit.

The controller in your cluster runs the file. If you stopped using dagweave tomorrow, every workflow would keep running, because Argo Workflows runs it, not dagweave.

  • Opens and runs in anything that reads Argo Workflows.
  • Roll back a bad workflow with git revert.
  • The same manifest dagweave dispatches to your cluster.
  • Drops straight into a GitOps loop you already run.
what lands in your repo yaml
apiVersion: argoproj.io/v1alpha1
kind: WorkflowTemplate
metadata:
  name: nightly-etl
spec:
  entrypoint: main
Publish

Commit, or open a pull request.

Pick the repo, the path, and the branch. dagweave writes straight to it, or opens a PR for review.

  • A workflow that spans several files writes as one atomic commit.
  • Use a token you pass in and we never store, or the dagweave GitHub App.
publish text
repo:   your-org/platform-workflows
path:   workflows/nightly-etl.yaml
mode:   pull request  ->  review  ->  merge

Keep your workflows where your code is.

dagweave is in early access. Leave an email and we will bring you on as we open it up.

Pre-launch. We store the address and nothing else, and we use it to tell you when we open up. No tracking, unsubscribe any time.