Git

Your workflows stay in your own repo.

Dagweave writes a standard Argo Workflows manifest to the repo and path you pick. It is Argo Workflows YAML and nothing else.

The problem

A workflow you cannot read in git.

A workflow you cannot read in git is a workflow your reviewers cannot review.

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.
Pushing to Git writes each reusable step as its own WorkflowTemplate file by default, or everything in one file if you prefer.
Drops straight into a GitOps loop you already run.

what lands in your repoyaml

apiVersion: argoproj.io/v1alpha1
kind: WorkflowTemplate
metadata:
  name: nightly-etl
spec:
  entrypoint: main

Linked from Git

Edit the WorkflowTemplates you already keep in Git

Already keep your WorkflowTemplates in Git? Link the folder. Dagweave follows every push, sends your edits back as a pull request, and never touches what Argo CD owns.

The canvas says which repo, file and commit you're looking at.
An edit isn't saved in Dagweave. It goes to Git when you push.

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.
Push with our GitHub App, or with a personal access token we use once and throw away.

publishtext

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.