Concourse CI
Container-native CI/CD system with a declarative pipeline model based on resources, tasks, and jobs. Concourse's key principle: every pipeline step runs in a container, pipelines are defined entirely in YAML, and no state is stored in containers (stateless workers). Originally built by Pivotal/VMware for Cloud Foundry deployments. Known for its reproducible, hermetic builds and elegant resource abstraction — any external state (Git repos, S3, Docker registries) is a 'resource'.
Score Breakdown
⚙ Agent Friendliness
🔒 Security
Apache 2.0 open source. OAuth2 with team/role-based access control. Credential manager integration (Vault, Kubernetes secrets). Stateless containers reduce persistent state attack surface.
⚡ Reliability
Best When
You need fully hermetic, reproducible pipelines with a clean resource abstraction and are willing to operate your own Concourse cluster — common in Cloud Foundry/Kubernetes shops.
Avoid When
You want SaaS CI, large pre-built integration libraries, or simple setup — GitHub Actions, CircleCI, or Semaphore are easier to start with.
Use Cases
- • Run hermetic, reproducible CI pipelines where every step is containerized and no state leaks between runs
- • Model complex multi-stage deployment pipelines with Concourse's fan-out/fan-in pipeline topology
- • Trigger pipelines from any external resource (S3 buckets, Git repos, Docker registries, time) using Concourse's resource abstraction
- • Deploy applications to Cloud Foundry or Kubernetes using Concourse's pipeline-as-code approach with no manual steps
- • Build agent CI workflows that react to external events (new Docker image, new artifact in S3) as first-class pipeline triggers
Not For
- • Teams wanting a large ecosystem of pre-built integrations — Concourse's resource model requires custom resources or community resources for non-standard integrations
- • Organizations needing a managed CI service — Concourse is self-hosted only; no official SaaS offering
- • Simple CI needs with broad community support — GitHub Actions or GitLab CI have vastly larger ecosystems
Interface
Authentication
Concourse uses OAuth2 with pluggable auth connectors (GitHub, GitLab, LDAP, local users). fly CLI uses OAuth tokens. Teams and roles for pipeline access control. REST API uses Bearer tokens.
Pricing
Concourse is Apache 2.0 open source. Originally Pivotal (now VMware) project. Community maintained. No commercial SaaS offering. Requires self-hosting on PostgreSQL + container runtime (Docker/containerd).
Agent Metadata
Known Gotchas
- ⚠ Concourse's resource model requires every external system to have a resource type — agents integrating custom systems must implement (or find) Concourse resource types
- ⚠ Pipeline YAML uses 'get' steps (pull resources) and 'put' steps (push to resources) — the mental model differs significantly from task-based CI; new users find it unintuitive
- ⚠ Concourse has no artifact storage built-in — intermediate build artifacts must be stored in external resources (S3, GCS) and explicitly passed between jobs via 'outputs'
- ⚠ fly login sessions expire — automated agents interacting with Concourse API must handle token refresh; fly targets store tokens locally
- ⚠ Concourse workers are stateless — any state from a previous build is gone after the container exits; agents expecting persistent workspaces must use external caches
- ⚠ Community resource types are maintained by the community, not Concourse team — quality, security, and maintenance varies; audit resources before use in production pipelines
Alternatives
Full Evaluation Report
Detailed scoring breakdown, competitive positioning, security analysis, and improvement recommendations for Concourse CI.
Scores are editorial opinions as of 2026-03-06.