# Tekton vs Argo Workflows — Kubernetes-Native CI/CD URL: https://www.devopsness.com/blog/tekton-vs-argo-workflows Author: Kiril Urbonas Published: 2026-07-14 Updated: 2026-07-14 Categories: DevOps Tags: Kubernetes, CI/CD, DevOps, ArgoCD, Tekton Summary: Both run pipelines as CRDs inside your cluster, but they were built for different jobs. Here's how Tekton and Argo Workflows actually differ in practice. --- # 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 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 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](/blog/best-cicd-platforms) 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.