Concourse

The design argument

Concourse's position is that build agents are the problem. A Jenkins agent accumulates state — installed tools, cached dependencies, environment drift — and over time builds pass or fail for reasons unrelated to the code. The familiar symptom is a pipeline that works on one agent and not another, with nobody able to say why.

Concourse runs every step in a container from a declared image, with explicit inputs and outputs. There is no persistent agent to drift. A task that worked last year works now, because its environment is specified rather than inherited.

Resources

Everything a pipeline consumes or produces is a resource: a git repository, an S3 object, a container image, a time trigger. Resources are typed and versioned, and a pipeline describes which resources it reads and writes.

This is the unfamiliar part. Engineers coming from GitHub Actions expect steps that run commands; Concourse asks them to think about versioned inputs flowing through jobs. The model is coherent and produces genuinely reproducible pipelines, but it is not what most people already know, and the adjustment is the main barrier to adoption.

The payoff is that the pipeline visualisation actually describes reality. Because inputs and outputs are declared, Concourse can draw the real dependency graph rather than a list of stages.

Operating it

Concourse is a web node, a database and worker nodes, and running it is infrastructure work. There is no hosted first-party offering, so adopting it means someone owns a CI platform. For a team that wants CI to be a checkbox, that is a poor trade. For a platform team already running Kubernetes and wanting pipelines that do not rot, it is more defensible.

Where it stands

The project originated at Pivotal and VMware and is now community maintained. Development continues but the community is small next to GitHub Actions or GitLab CI, which shows up as fewer prebuilt integrations and fewer answers when something obscure breaks.

Pick Concourse for build reproducibility as a hard requirement. Pick something mainstream if ecosystem size and low operational overhead matter more.

Compared with the mainstream options

Against GitHub Actions, the trade is reproducibility for convenience. Actions has an enormous marketplace, runs with no infrastructure, and integrates with the repository by default; it also runs on managed runners whose contents change over time, and pipelines written as a chain of community actions inherit whatever those actions do.

Against Jenkins, the trade is roughly the reverse of Jenkins's own weakness. Jenkins will do anything given enough plugins, and that flexibility is exactly what produces unmaintainable pipelines and drifting agents. Concourse is less flexible on purpose.

Operating characteristics

Pipelines are set with fly set-pipeline from version-controlled YAML, and there is no clickable configuration to diverge from the file. That makes the repository the source of truth in a stronger sense than CI systems where UI changes are possible.

Worker capacity is the usual scaling constraint, since every step wants a container. Teams running Concourse on Kubernetes generally end up tuning worker counts and container limits as a regular operational task rather than a one-time setup.