Tekton vs Argo Workflows — Kubernetes-Native CI/CD

We ended up running both for a while, not by design. One team had built their CI on Tekton before I joined, and the data platform folks were already deep in Argo Workflows for their nightly ETL. When the mandate came to pick one, the debate got heated fast, and most of the heat came from people who'd only used one of them. So we ran the same build on each for a couple of sprints and let the friction points settle the argument.

Both are CNCF projects. Both run entirely inside Kubernetes, defining pipelines as custom resources instead of shipping a separate scheduler or a bespoke DSL. If you already have a cluster and RBAC and monitoring, that shared foundation is the whole appeal. But underneath, they were built to solve different problems, and that shows up the moment you write your second pipeline.

How each one models work #

Tekton is built around small, reusable pieces. A Task is a set of steps that run in one pod. A Pipeline wires Tasks together with ordering and shared workspaces. When you actually run something, you create a PipelineRun (or a TaskRun), which is the execution record you go look at afterward. The big idea is reuse: a Task like git-clone or buildah gets pulled straight from the Tekton Hub and dropped into any pipeline. You assemble CI from parts other people already wrote and hardened.

yaml.yaml

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
name: build-and-test
spec:
workspaces:
- name: source
tasks:
- name: clone
taskRef:
name: git-clone
workspaces:
- name: output
workspace: source
- name: test
runAfter: [clone]
taskRef:
name: golang-test
workspaces:
- name: source
workspace: source

Argo Workflows thinks in terms of a single Workflow object made of templates. A template can be a container, a script, a set of sequential steps, or a dag with explicit dependencies. The DAG is the thing people reach for. You declare which node depends on which, and the controller figures out the parallelism.

yaml.yaml

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: build-and-test-
spec:
entrypoint: main
templates:
- name: main
dag:
tasks:
- name: clone
template: git-clone
- name: test
template: go-test
dependencies: [clone]
- name: git-clone
container:
image: alpine/git
command: [git, clone, "$(REPO)", /work]
- name: go-test
container:
image: golang:1.24
command: [go, test, ./...]

Read those two side by side and the difference is clear. Tekton pushes you toward named, versioned, shareable Tasks. Argo lets you inline everything in one file and get moving, which is faster for a one-off and messier once you have thirty of them.

What each was actually built for #

This is the part that gets glossed over. Tekton is a CI/CD engine, full stop. Every design choice, from workspaces to results to the way it handles credentials, assumes you're cloning code, building an image, running tests, and pushing an artifact. If that's your whole world, Tekton fits your world exactly.

Argo Workflows is a general-purpose workflow engine that happens to be very good at CI. People use it for data pipelines, batch jobs, and ML training runs where a DAG of steps needs to fan out across hundreds of pods and fan back in. If your org already runs Argo Workflows for ETL or model training, using it for CI too means one engine, one UI, one set of habits. That gravity is real and it's the single biggest reason teams land on Argo.

Triggering, UI, and the surrounding kit #

Neither ships a git-webhook listener in the core engine. Tekton has a separate project, Tekton Triggers, with an EventListener that takes a webhook, runs it through an interceptor, and spins up a PipelineRun. It's fiddly to set up the first time and rock solid after. The Tekton Dashboard gives you a read-only view of runs, which is fine but not going to win any awards.

Argo's answer is Argo Events, a separate component with event sources and sensors that can trigger a Workflow from far more than git, think S3 drops, message queues, cron. The Argo Workflows UI is genuinely nicer: the live DAG view, with nodes turning green as they finish, is the thing that makes people fall for it in demos. It also slots next to Argo CD and Argo Rollouts if you want the full Argo stack under one roof, which is a common reason teams pick a CI/CD platform and stay in one ecosystem.

Artifacts and parallelism #

Argo has first-class artifact passing baked in. A step writes an output, names it, and a downstream step consumes it, with S3, GCS, or MinIO as the backing store configured once at the controller. For data-heavy DAGs that's exactly right. Parallelism is declarative too: withItems and withParam fan a template out over a list without you writing a loop.

Tekton passes small values between Tasks through results and larger data through shared workspaces backed by a PVC. It works, but you feel the plumbing more, and cross-Task data handoff takes more thought than it does in Argo. Parallel Tasks run when their runAfter dependencies allow, which covers CI fan-out fine but doesn't match Argo's ergonomics for wide, dynamic fan-out.

Side by side #

| Tekton | Argo Workflows
Primary purpose | CI/CD, purpose-built | General DAG engine, strong at CI
Core objects | Task, Pipeline, PipelineRun | Workflow, templates (steps/DAG)
Reuse model | Versioned Tasks from Tekton Hub | Templates, WorkflowTemplates
Triggering | Tekton Triggers / EventListener | Argo Events
UI | Tekton Dashboard (basic) | Argo Workflows UI (live DAG)
Artifacts | results + workspace PVCs | Native S3/GCS artifact passing
Dynamic fan-out | Manageable, more manual | withItems / withParam, native
Best fit | CI/CD-first standardization | ML, data, and CI in one engine

The call we'd make #

Pick Tekton if CI/CD is the job and you want a standard built for that job. The Hub Tasks, the reusable pieces, and the tight scope pay off when a dozen teams need pipelines that look the same and don't drift. It asks more of you upfront and rewards you with consistency.

Pick Argo Workflows if you also run data or ML pipelines, or if you're already living in the Argo ecosystem. One engine covering CI, ETL, and training runs is worth more than a marginally better fit for pure CI, and that UI keeps people from filing tickets. We landed on Argo Workflows in the end, not because it's the better CI tool, but because it let us delete a second engine. If our shop had been CI and nothing else, we'd have kept Tekton without a second thought.