Tekton

Building blocks for CI/CD systems as Kubernetes resources: each Task runs as a pod, each step in it as a container, and Pipelines chain Tasks together.

CNCF · Incubating

What it is: CI/CD pipelines
Type: Open source
Made by: Cloud Native Computing Foundation
Foundation: Cloud Native Computing Foundation, incubating, joined March 2026. Part of the Linux Foundation
License: Apache 2.0
Facts checked: 28 October 2026

What it is

Tekton Pipelines installs into a Kubernetes cluster and adds custom resources. A Task is an ordered list of steps, and each step names a container image and a command or script. When a TaskRun starts the Task, Tekton creates one pod for it with one container per step, run in order until the first failure. A Pipeline arranges Tasks into a graph, and a PipelineRun runs it. Because every Task gets its own pod, Tasks share nothing by default: files travel between them through workspaces, which are volumes, and small values through results, whose size is capped by Kubernetes’ container termination message.

Pipelines is the core of a set of components, aimed at platform teams building CI/CD for their developers rather than at developers directly. Triggers starts runs from events such as a merged pull request, Pipelines-as-Code reads definitions from a .tekton/ directory in the repository, tkn is the command line, the Dashboard a web UI, and Chains records provenance for what a run built and signs it with keys from cosign or a KMS, or keylessly through Sigstore. Red Hat OpenShift Pipelines and IBM Cloud Continuous Delivery are built on it. Pipelines reached 1.0 in May 2025 and ships monthly, with four releases a year supported long term; the latest is 1.17.1, from October 2026. Tekton was a graduated project of the Continuous Delivery Foundation and moved to the CNCF as an incubating project in March 2026.

Why teams pick it

Everything is a Kubernetes resource, so pipelines are applied, versioned and secured like any other workload, with no separate CI server
Any container image can be a step, and each Task runs in its own pod, isolated from other runs
Reusable Tasks and Pipelines can be shared across teams and pulled from the community Catalog
Supply-chain features built in: Chains signs build results and records SLSA provenance

Watch out for

Needs a Kubernetes cluster, and every Task pays for starting a pod
Tasks share no files by default: data must go through workspaces or results, and results are limited in size
A toolkit rather than a finished product: triggers, UI and repository integration are separate components, and the project calls its Dashboard a work in progress
Releases other than the four LTS lines a year are supported for about a month, so clusters need regular upgrades

Alternatives

What all ci/cd pipelines have in common →Compare side by side →

Argo CDOpen sourceGitOps delivery for Kubernetes: a controller in the cluster keeps what’s running identical to the manifests in a Git repository.

GitHub ActionsCommercialCI/CD built into GitHub: YAML workflows in the repository run on GitHub’s VMs or your own machines whenever something happens in the repo.

JenkinsOpen sourceThe self-hosted automation server much of CI started on: a Java controller that hands jobs to agents, more than 2,300 plugins, and pipelines written as a Jenkinsfile.

CodecovCommercialA hosted code coverage service: CI jobs upload the coverage reports their tests produce, and Codecov merges them per commit and reports on each pull request how well the changed lines are tested, with a status check that can block the merge.

KernelCIOpen sourceContinuous integration for the upstream Linux kernel: it builds kernel trees in many configurations, boots and tests them on real boards in community labs, and collects results from other kernel CI systems in one public database.

SigstoreOpen sourceSigning for releases, images and packages without keys to manage: a short-lived certificate tied to a login or CI job, and a public log of every signature.

How it fits with other technologies

What Tekton uses

A Task with two steps, run once against a checked-out repository · yaml

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: unit-tests
spec:
  workspaces:
    - name: source            # a volume the steps share
  steps:                      # each step is a container in the same pod
    - name: install
      image: node:22
      workingDir: $(workspaces.source.path)
      script: npm ci
    - name: test
      image: node:22
      workingDir: $(workspaces.source.path)
      script: npm test
---
apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
  generateName: unit-tests-run-   # kubectl create -f run.yaml
spec:
  taskRef: { name: unit-tests }
  workspaces:
    - name: source
      persistentVolumeClaim: { claimName: repo-checkout }

See it in a real stack

No architecture uses Tekton yet. Drop it into the playground and wire it up yourself.Open playground →

Where it came from2018–2026

By 2018 many CI/CD systems ran on Kubernetes, and each rebuilt the same basic machinery for running build steps in containers. Engineers at Google, among them Dan Lorenc, sketched a set of shared resources inside the Knative project in August 2018; the code lived in knative/build-pipeline, and the aim, in Lorenc’s words, was to “make the hard parts of building CI/CD systems easy”.

In February 2019, just before its 0.1 release, the team split the project out of Knative, named it Tekton and gave it to the new Continuous Delivery Foundation, where it was a founding project in March. Knative Build was deprecated in favour of Tekton Pipelines that June. Tekton graduated at the CDF in October 2022 after an independent security audit, and Pipelines reached 1.0 in May 2025, after its v1 API had been stable for more than two years.

In March 2026 the CNCF accepted Tekton as an incubating project, putting it alongside Kubernetes, Knative and Argo, which it already worked with. The project said nothing changed for users and that its governance and infrastructure would move to CNCF processes over time.

Why it’s built this way

Building blocks, not a CI product: Many Kubernetes CI/CD systems were rebuilding the same infrastructure. Tekton aimed to be the common layer underneath, so it defines resources and controllers and leaves user interfaces and opinions to the products built on top, such as OpenShift Pipelines.
A Task is a pod and a step is a container: Reusing Kubernetes’ own scheduling and isolation meant any container image could be a build step, and each run is kept apart from others in its own pod.
Kubernetes custom resources as the API: Defining Tasks and Pipelines as resources lets teams apply, secure and audit them with the same tools and RBAC they already use for everything else in the cluster.

Timeline

2018
Design sketched in August; code grows inside Knative as build-pipeline
2019
Split out and named Tekton in February; founding CDF project in March
2022
Graduates at the Continuous Delivery Foundation in October
2025
Tekton Pipelines 1.0 in May
2026
Accepted into the CNCF as an incubating project in March

Sources10 · facts checked 28 October 2026

Improve this page on GitHub