Concourse runs automated pipelines that turn source changes into tested, publishable software. A pipeline declares the inputs to watch and the jobs to run, while workers execute the individual tasks. Teams use it to keep their build process visible and reproducible through configuration stored with their code. On Kubernetes, the web service, database and build workers have different needs; a working dashboard alone does not mean jobs can run correctly.
Deployment and operating notes
Concourse’s current installation documentation links an official chart in concourse/concourse-chart. The retired stable chart should not be used as the deployment authority. Concourse’s web service, database and workers have different persistence and privilege requirements; an apparently healthy web pod does not establish that tasks can execute safely.
Inventory pipeline resources, custom resource-type images, credential-manager integrations, authentication and encryption or signing keys before upgrading. Back up the database and protect the keys needed to read existing secrets. Review the worker runtime, required privileges, storage and network access for the selected Concourse release and cluster policy. Test a representative pipeline from resource discovery through task execution and artifact publication, including a failed task and cancellation. Let existing work finish or follow the documented worker retirement process before replacing workers. A previous chart may not understand a migrated database, so treat restore compatibility separately from Helm rollback. Keep build credentials scoped to the pipelines that need them.
Historical upstream link check · 2026-10-09
The recorded upstream address responded successfully (HTTP 200) on 2026-10-09. GitHub confirms that helm/charts is archived: this is a historical chart distribution, not evidence that the application itself is retired. Link availability does not certify the historical installation instructions or current security support.
Website availability is separate from project, chart and image support. Use the current guidance and primary sources on this page to assess the distribution.
Historical Kubedex content
Preserved for context. Commands, versions, prices and results below reflect the original research.
This chart bootstraps a Concourse deployment on a Kubernetes cluster using the Helm package manager. Concourse is 100% open source CI/CD system with approximately 100 integrations to the outside world. Concourse’s principles reduce the risk of switching to and from Concourse, by encouraging practices that decouple your project from your CI’s little details, and keeping all configuration in declarative files that can be checked into version control.
Prerequisites Details
- Kubernetes 1.6 (for pod affinity support)
- PV support on underlying infrastructure (if persistence is required)
Configuration As Code
You can think of a pipeline as a distributed, higher-level, continuously-running Makefile.
Each entry under resources is a dependency, and each entry under jobs describes a plan to run when the job is triggered (either manually or by a get step).
Jobs can depend on resources that have passed through prior jobs. The resulting sequence of jobs and resources is a dependency graph that continuously pushes your project forward, from source code to production.
Fancy Visualization
Your pipeline configuration is then visualized in the web UI, taking only one click to get from a red (failed) box to seeing why it failed. The visualization also provides a “gut check” feedback loop – if it looks wrong, it probably is wrong.
CI Under Source Control
All administration is done using the fly CLI. The fly set-pipeline command pushes the config up to Concourse. Once it looks good, you can then check the file into source control. This makes it easy to recover if your Concourse server burns down.
Reproducible, Debuggable Builds
Everything runs in containers, ensuring a clean environment on every run. Each task specifies its own image, giving it full control over its dependencies, rather than managing them on your workers. The fly intercept command will pop you right into one of your build’s containers, which can be useful for debugging.
Rapid Local Iteration
The fly execute command executes a task as a one-off build, with your local changes. This will run your code in exactly the same way it would run in your pipeline, without you having to repeatedly push broken commits until it works. Achieve the fabled green build #1!
When a job fails, you can also use fly execute with -j flag to run with the same inputs as the failed job. You can then replace an input with your local changes with -i to test if your fix is valid.
Bring Your Own Integrations
Concourse does not have a complex plugin system. Instead, it has a single strong abstraction.
The resources section of a pipeline lists Resources, which are abstract external locations where your pipeline will monitor for changes, fetch bits from, and push bits to.
For example, a resource with type git refers to a git repository, which will be cloned in a get step and pushed to in a put step. Behind the scenes, Concourse will continuously run git fetch to look for new commits that jobs may want to trigger on.
At its core, though, Concourse knows nothing about Git. It comes with a git resource type out of the box, but you could just as easily bring your own into your pipeline. Resource types are implemented as container images containing scripts – using the docker-image resource type, they can be fetched from a Docker registry.
Sources & further reading
Spotted something that needs another look?
Help improve this page →