Concourse

Concourse is another CI/CD tool I run in production — including standing up team-dedicated worker pools and tuning garbage collection at real scale, not just reading the docs. No specific employer infrastructure described here, just the general model and why it’s worth understanding even if Jenkins is your daily driver.

The core idea

Concourse is resource-and-pipeline-centric rather than job-and-plugin-centric. Everything is declared as a resource (a Git repo, a Docker image, a time trigger, an S3 bucket — anything with versions) and a set of jobs that consume and produce new versions of those resources. Every task runs in a fresh, ephemeral container — there’s no persistent build-agent state carried between runs the way there often is in Jenkins.

That statelessness is the whole design philosophy: a job that passes today should pass identically tomorrow, because nothing about the execution environment is allowed to drift.

Where it fits

The time resource makes Concourse a genuinely good fit for cron-style, recurring jobs — nightly rebuilds, periodic scans, scheduled cleanup — in a way that’s more declarative and observable than a raw crontab: every run is a versioned entry in a pipeline you can look at, not a line in a file you have to SSH in to remember exists. For build/test with human- or API-driven parameterized inputs, Jenkins tends to be the better tool; for deployment, see ArgoCD.

Principles

• Config as code — no UI for defining pipelines, enforced by the tool itself.
• Versioned resources — immutable, versioned inputs over mutable job state.
• Ephemeral containers — every task runs clean, which surfaces hidden dependencies fast.
• Setup & Sizing — worker resource limits, garbage collection, and general tiering.
• Team-scoped workers via Helm — dedicating worker capacity to a specific team.

Why it’s worth knowing even if you use something else

The value of learning Concourse’s model isn’t switching tools — it’s that “config as code” and “immutable versioned inputs” are good defaults to bring back to whatever CI system you actually use day to day, including Jenkins.