Argo Workflows
Argo Workflows is a CNCF-graduated workflow engine implemented as a Kubernetes custom resource: each step of a DAG runs in its own container, workflows are declared in YAML and submitted to the cluster, and the scheduler is the Kubernetes control plane rather than a separate application.
LicenseOpen source (permissive)· Apache-2.0
DeploymentSelf-hosted
PricingFree
Operational complexityHigh
WorkloadBatch
LanguageGo
Use it when
- Kubernetes is already the platform; workflows become custom resources scheduled by the control plane you run anyway.
- Every step should be a container, inheriting resource requests, node affinity, secrets, and RBAC from the cluster.
- Fan-out is large and parallel: ML pipelines, batch processing, CI/CD.
- CNCF-graduated, vendor-neutral governance is a requirement.
Think twice when
- There is no Kubernetes cluster; Argo has nothing to run on.
- Authors want Python functions rather than YAML and container images; Flyte layers typed Python on the same substrate, and Argo's official Python SDK was removed in 4.0.
- The work is data modelling: there are no assets, no lineage, and no dbt integration; Dagster speaks that language.
- Artifacts need a repository configured before any file can pass between steps at all.
How it runs
Installed as manifests or a community Helm chart, scoped to the cluster, a namespace, or managed namespaces. Each step runs as a container in its own pod and Kubernetes schedules it; CronWorkflow covers time triggers and WorkflowEventBindings start runs from webhooks. Parameters travel inline; artifacts go through S3-compatible storage. CNCF-graduated, Apache-2.0, free.
Details
CompareHow Argo Workflows answers the questions Workflow Orchestration turns on.
Workflow Orchestration
| How it works | |
| Authoring model | Kubernetes custom resources: a workflow is an object submitted with kubectl |
| Unit of work | A template inside a Workflow custom resource (container, script, resource, suspend, http, plugin or containerSet) wired together by steps or dag templates; WorkflowTemplate and its cluster-scoped twin make them reusable |
| Passing data | Parameters inline in the object, artifacts through a repository (S3, GCS, Azure Blob, Artifactory, HDFS, OSS, Git, HTTP or raw) and one must be configured before any artifact runs at all; the workflow is an etcd object capped at 1MB, so node status is compressed and then offloaded to Postgres, MySQL or MariaDB |
| Triggers | CronWorkflow for schedules (a list of cron expressions, an IANA timezone, concurrencyPolicy and startingDeadlineSeconds) plus a built-in events API where a WorkflowEventBinding maps a webhook payload onto a WorkflowTemplate; anything richer means Argo Events, a separate project |
| Delivery guarantee | A retryStrategy per step: Always · OnFailure · OnError or OnTransientError |
| Caching and reruns | memoize on a template, keyed by an expression over its inputs, with maxAge as the ttl and entries kept in a labelled ConfigMap, so 1MB bounds what it can hold; since 3.5 any step can be memoized, not only those producing outputs |
| Running it | |
| Where tasks run | One container in a pod per step; Kubernetes does the scheduling |
| Connections | |
| Task languages | Whatever the image holds: a container template runs any image, and a script template writes the source to a temp file and hands it to an interpreter, so image plus command decide the language; Bash, Python and Node are the documented examples. 4.0 removed the official Python SDK, leaving the community's Hera |
| Connectors | No catalogue, by design: a step is a container, so the integration is whatever the image can do; the built-in reach is artifact repositories, executor plugins and an http template |
| Cost | |
| Billing unit | Nothing to pay: a CNCF-graduated project with no paid tier, so the bill is the cluster, the artifact repository and the optional Postgres or MySQL behind offloaded status; Pipekit and Akuity sell a control plane and enterprise support around it |
Alternatives to Argo Workflows
