dagweave Connector

dagweave Connector ProBusiness

The dagweave Connector is a small Kubernetes operator you run in your own cluster. It bridges your Argo Workflows instances to dagweave so the app can submit workflows and collect their status, logs, and artifacts. This is the one piece a cluster operator sets up, usually once, so that workflow authors can run their workflows on your cluster. You only need it if you want dagweave to run workflows for you. If you just want the YAML, copy it from the builder and apply it yourself. Running workflows through the connector needs a plan that includes it.

How it connects

The connector is always the client. It opens a single outbound channel to dagweave and every message rides on that one connection. dagweave pushes work down the channel and receives results back up it. Your cluster never has to accept inbound traffic, so you do not open a port or expose an ingress for dagweave.

A few properties worth knowing before you install:

• It rides on Argo Workflows’ own CRDs. dagweave ships already-compiled Workflow, WorkflowTemplate, and CronWorkflow manifests, and the connector applies them as-is for the Argo Workflows controller to run. The connector’s own CRDs carry configuration only. There is no bespoke run CRD to drift from the Argo Workflows schema.
• It runs HA by default. The manager runs two replicas in active/standby with leader election, so only one replica ever dispatches. Two writers would submit duplicate runs.
• Features are toggleable with least-privilege RBAC. Four features (submit, status, logs, artifacts) each gate their own block of RBAC rules. Turn a feature off and its permissions are never installed.
• Artifacts stay in your storage. Workflow artifacts live in your own S3 or S3-compatible store. The connector mints short-lived presigned URLs and never copies the bytes.
• Logs go straight to your sink. With logs enabled, the chart deploys a Vector DaemonSet that tails Argo Workflows pod logs and ships them to a sink you own. Log bytes never pass through dagweave.

Install with Helm

Add a connector in the dagweave UI and it hands you a ready-to-run install command with a one-time enrollment token baked in. The token is shown once, so copy the command before you dismiss it. Run it against your cluster:

helm install connector oci://ghcr.io/dagweave/charts/connector \
  --namespace connector-system --create-namespace \
  --set connectorConfig.dagweaveEndpoint=https://api.dagweave.com \
  --set-string enrollment.token=<one-time-enrollment-token>

The chart installs the operator with HA defaults, the two CRDs, per-feature RBAC, and the enrollment Secret. On first start the connector trades the one-time token for a durable identity: it presents an ed25519 key, dagweave binds that key, and every later call authenticates with it. A restart re-enrolls with the same key and is a no-op; a stolen token presented with a different key is refused.

Connect an Argo Workflows instance

Argo Workflows is often installed per namespace, so one cluster can host several instances. You model each one with an ArgoConnection. Create one per instance you want dagweave to manage:

apiVersion: connector.dagweave.com/v1alpha1
kind: ArgoConnection
metadata:
  name: team-a
spec:
  argoInstanceID: team-a
  namespaces: [team-a]
  features:
    submit: true
    status: true
    logs: true
    artifacts: true

Commands and status are routed and feature-gated per connection. For several clusters, install one connector in each. dagweave aggregates across them; a single connector does not route across clusters.

Health and version

Each connector shows its state in the dagweave UI. A connector is pending until the agent first phones home, online while it heart-beats, and offline once the beats stop for about a minute. The row also shows the running connector version and, once it heartbeats, the Argo instances it serves. dagweave never dials in to check; the state comes from the connector’s own heartbeat. When dagweave has a newer validated connector version, it asks an out-of-date connector to update itself on its next heartbeat.

Once connected

With a cluster connected, workflow authors can attach triggers to a workflow and run it from dagweave: a manual button, a cron schedule, a webhook, GitHub, or an AWS SNS notification. Each run then shows up in the executions view with its logs, metrics, and a re-run button, and run provenance is tracked, so you can see which trigger fired a given run.