Concourse

What it is

Concourse is an open-source CI/CD automation system built around a distinctive pipeline model: everything is expressed as resources (things that produce or consume versioned artifacts — git repos, S3 buckets, Docker images, time triggers) and jobs that pull those resources through a sequence of tasks. Pipelines are defined declaratively in YAML and pushed via the fly CLI rather than authored through a web UI. Every task runs in an isolated, ephemeral container, so there's no persistent build agent state to worry about — each run starts from a clean environment defined by the pipeline itself. It sits in the App Definition and Development category alongside other CI/CD and workflow tools, but its container-native, stateless execution model is closer to a distributed task scheduler than a traditional Jenkins-style CI server.

Who builds it and why

Concourse originated out of the Cloud Foundry/Pivotal ecosystem, built to solve CI/CD problems for teams shipping complex, multi-component platform software (Cloud Foundry itself was an early and demanding user). It's maintained as an independent open-source project today, not under CNCF governance (CNCF maturity: not publicly available — it isn't currently a CNCF project). Development is driven by a mix of core maintainers and a broad contributor base (595 contributors on GitHub), with the project written entirely in Go. Ongoing commit activity through mid-2026 indicates it's still actively maintained, not abandoned.

Production readiness signal

• 7,853 GitHub stars — a modest but stable following; smaller than Jenkins, GitHub Actions runners, or Tekton in mindshare.
• 595 contributors — a healthy, diverse contributor base for a project of this scope, suggesting it's not a single-vendor pet project.
• Latest release v8.2.4 — mature versioning, well past initial 1.0 stability concerns.
• Recent commit activity — actively maintained, not stagnant.
• License: Apache-2.0 — standard permissive OSS license, no rug-pull risk from licensing changes.
• CNCF maturity level and founding date are not publicly available, so you can't lean on CNCF's due-diligence process as a trust signal here — you have to evaluate the project on its own GitHub activity and community footprint.

Who should use this

Teams that want reproducible, hermetic pipelines where "it works on my machine" isn't an excuse — because every task runs in its own container from a defined image, every time. Good fit for infrastructure and platform teams building complex multi-stage delivery pipelines (build → test → deploy → promote across environments) who want pipeline-as-code with strong versioning semantics via resources. Organizations already running Concourse for Cloud Foundry-adjacent workflows, or teams that prioritize declarative, stateless CI over UI-driven pipeline construction, will find it a natural fit.

Who should NOT use this

If your team wants a low-friction CI setup with a big plugin marketplace and lots of Stack Overflow answers, look elsewhere — Concourse's resource model has a real learning curve and its ecosystem of pre-built integrations is far smaller than Jenkins or GitHub Actions. Teams wanting tight native integration with GitHub/GitLab (PR checks, status UI, marketplace actions) will find Concourse comparatively bare-bones. It's also not the right choice if you need a large hosted/managed offering with enterprise support contracts — Concourse's commercial ecosystem is thin compared to alternatives. Small teams or solo projects needing quick, zero-config pipelines will find the operational overhead (running and maintaining the Concourse server/worker topology) disproportionate to the benefit.

Alternatives

• Tekton — Kubernetes-native CI/CD building blocks, CNCF project, better fit if you want K8s CRDs driving pipelines.
• Jenkins — far larger plugin ecosystem and community, but carries more operational and security debt.
• GitHub Actions / GitLab CI — tightly integrated with their respective source control platforms, far lower setup overhead for teams already on those platforms.

Pricing

Fully open source under Apache-2.0. No paid tier, no dual-licensing model publicly documented. You pay only in infrastructure and operational cost to run and maintain it yourself.