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.

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.

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#

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.