# Concourse: a container-based CI system with no GUI for configuration

> Concourse is an Apache-2.0 automation system written in Go, distributed as a single binary and driven by declarative YAML pipelines. It suits teams that want reproducible builds and stateless workers, and it will frustrate anyone who wants to click a pipeline together.

**concourse/concourse** — Concourse is a container-based automation system written in Go. It's mostly used for CI/CD.

- Repository: https://github.com/concourse/concourse
- Website: https://concourse-ci.org
- Stars: 7,909 · Forks: 904
- Language: Go
- License: Apache-2.0
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/concourse-concourse

## What Concourse actually automates, and for whom

Concourse is an automation system written in Go, and the README says it is most commonly used for CI/CD. The scope is wider than that sentence suggests: the project describes itself as built to scale to any kind of automation pipeline, from simple to complex. The unit of work is a pipeline, and a pipeline is a YAML file, not a sequence of clicks in a web form.

The README is explicit on this point: Concourse has no GUI for configuration. That single design decision determines who the tool is for. If your team already stores build definitions in Git and reviews them like code, the model fits. If your workflow depends on a visual editor, a drag-and-drop job builder or per-job settings that live only in a database, Concourse is the wrong shape and no amount of configuration will change that.

The stated opinions are idempotency, immutability, declarative config, stateless workers and reproducible builds. Those are not marketing adjectives here; they describe constraints the rest of the system enforces. A worker holds no durable state, so a job can land on any available worker. Immutability means a build's inputs are pinned rather than patched in place. Anyone evaluating Concourse should read that list as a description of what they are agreeing to, not as a feature list.

## How a Concourse pipeline is structured

A pipeline file has two top-level keys that matter immediately: resources and jobs. A resource names an external thing Concourse can fetch or push, such as a Git repository, and carries a type plus a source block describing where that thing lives. A job is a named sequence of steps, called a plan, that consumes and produces those resources.

The README's example shows the shape: a resource named examples of type git with a source uri pointing at the concourse/examples repository, and a job named hello-world whose plan begins with a get step. That is the whole configuration surface in miniature. There is no separate build script registry and no implicit working directory contract beyond what the steps define.

Because workers are stateless, each job step runs in a fresh container rather than on a long-lived machine that accumulates state between runs. The repository layout reflects the split: the atc directory holds the web/API component, worker holds the worker component, fly holds the CLI, and tsa handles worker registration traffic. The docker-compose.yml in the repository runs web and worker as separate services from the same image, which is the clearest statement of the architecture available without running it. The web service talks to PostgreSQL and exposes port 8080; the worker registers with the web service and runs containers.

## Installing Concourse and running a first pipeline

The README says Concourse is distributed as a single concourse binary, available on the Releases page. It also lists three other supported formats, each in its own repository: a Docker image, a Kubernetes Helm chart and a BOSH release. For a first look, the README points at the Quick Start, which uses Docker Compose.

The Quick Start fetches a compose file and brings the stack up in the background. The README shows the command and the resulting containers:

```bash
wget https://concourse-ci.org/docker-compose.yml
docker-compose up -d
```

After that, the README states Concourse is running at http://localhost:8080 and you can log in with the username and password test/test. The repository's own docker-compose.yml defines the same port mapping, 8080:8080, and sets CONCOURSE_ADD_LOCAL_USER to test:test,guest:guest with CONCOURSE_MAIN_TEAM_LOCAL_USER set to test.

Next you install fly, the CLI, by downloading it from the web UI at http://localhost:8080/download-fly, then target the local instance. The README gives this exact sequence:

```bash
fly -t ci login -c http://localhost:8080 -u test -p test
```

The expected output is a line reading logging in to team 'main' followed by target saved. From there the README points at the Getting Started Tutorial for writing pipelines. The pipeline itself is a YAML file, and the README's example opens like this:

```yaml
resources:
- name: examples
  type: git
  source:
    uri: https://github.com/concourse/examples
```

One thing worth noticing in the repository's compose file: the worker service runs with privileged: true and cgroup: host. That is not incidental. A local Concourse worker needs those settings to run containers, and any environment you deploy into has to permit the equivalent.

## Where Concourse gets awkward

The configuration model is the first limitation. The README states plainly that there is no GUI for configuration, and pipelines are declarative YAML files. For a team without an existing review process for pipeline changes, this turns every job tweak into a file edit, a commit and a fly set-pipeline invocation. That is a workflow cost, not a bug, but it is real.

The worker requirements are the second. The repository's docker-compose.yml runs the worker with privileged: true and cgroup: host, and maps ports 7777 and 7788. If your platform forbids privileged containers, or your security policy treats host cgroup access as unacceptable, the standard deployment shape does not apply to you and you are looking at a constrained setup rather than the documented one.

The third is the state of the roadmap. The README carries a long commented-out section titled The road to Concourse v10, and inside it the project states that v10 will make Concourse not suck for multi-branch and/or pull-request driven workflows, describing those as cases of spatial change where the set of things to automate grows and shrinks over time. Several entries in that table are marked experimental or pending. Instanced pipelines are listed as arriving in v7.0.0 experimental; the dynamic across step is marked experimental and not released yet as of that text. The README also notes the roadmap posts are slightly out of date. Treat that comment block as a statement of intent, not a shipping promise.

## Concourse compared with a YAML-in-repo runner like GitHub Actions

The closest comparison for most teams is a hosted CI service that also reads YAML from the repository, such as GitHub Actions. Both put pipeline definitions in version control, and both run each job in a fresh environment. The difference is where the execution happens and who owns the runner.

With a hosted service, the provider supplies the machines and you accept its execution model, its secrets handling and its scheduling limits. With Concourse you run the web and worker components yourself against your own PostgreSQL, which the docker-compose.yml makes visible: the db service uses image postgres with a healthcheck, and the web service waits on it with condition: service_healthy. You get control over the worker and over where build containers run, and you take on the operational work that comes with it.

The second difference is the configuration surface. Hosted runners typically expose a web UI for editing workflows alongside the file. Concourse does not, by design. If your team's review culture is strong and your platform team is comfortable operating stateful services, the Concourse model is coherent. If either of those is missing, the hosted option removes a class of problems you would otherwise inherit.

## Maintenance, upgrades and the Apache-2.0 licence

The repository is not archived, and the last push was on 2026-09-20. Recent releases listed are v8.3.0 on 2026-08-13, v8.2.5 on 2026-08-03 and v8.2.4 on 2026-06-16. That is a steady release cadence across the summer, with a patch release between the two feature releases.

Upgrade cost depends on which of the four distribution formats you chose, because the README lists them as separate repositories: the single concourse binary, the Docker image, the Helm chart and the BOSH release. A binary install means downloading the new release and restarting the web and worker processes. A chart or BOSH install means bumping a version in your deployment manifest and letting the tooling roll it out. In all cases the database is yours to migrate, since the compose file shows Concourse pointing at an external PostgreSQL rather than embedding one.

Concourse is licensed under Apache-2.0, and the web package.json carries the same identifier. Apache-2.0 permits commercial use and modification and includes an explicit patent grant, with the usual obligations around preserving notices and stating changes. The repository ships LICENSE.md and NOTICE.md at the top level, so the notice file is part of what you redistribute if you ship a modified build. This is a description of the licence text, not legal advice; have counsel review anything you redistribute.

## Conclusion

Adopt Concourse if your team is comfortable keeping every pipeline in a YAML file under version control and can run privileged workers, because the system assumes both. Do not adopt it if you need a browser form to define or edit jobs, or if you cannot give the worker container privileged mode and host cgroups. Before committing, verify that your chosen install path (the single concourse binary, the Docker image, the Helm chart or the BOSH release) matches the version you intend to run, and confirm which PostgreSQL you will point CONCOURSE_POSTGRES_HOST at.

## FAQ

### What is Concourse CI and what is it used for?

Concourse is a container-based automation system written in Go, and the README says it is most commonly used for CI/CD but built to scale to any kind of automation pipeline. Pipelines are defined in declarative YAML files rather than through a GUI.

### How do I install Concourse?

The README states Concourse is distributed as a single concourse binary available on the Releases page, with additional supported formats for Docker, Kubernetes (Helm) and BOSH, each in its own repository. For a quick look, the README's Quick Start downloads a docker-compose.yml and runs docker-compose up -d, after which Concourse is available at http://localhost:8080.

### What is the fly CLI in Concourse and how do I log in?

fly is the Concourse command line interface, downloaded from the web UI at http://localhost:8080/download-fly. The README shows logging in with fly -t ci login -c http://localhost:8080 -u test -p test, which prints logging in to team 'main' and then target saved.

### Does Concourse have a web interface for editing pipelines?

No. The README states that Concourse has no GUI for configuration and that pipelines are defined in declarative YAML files instead. The web UI is used for viewing and for downloading fly, not for authoring pipeline configuration.

### What licence is Concourse released under?

Concourse is licensed under Apache-2.0, and the repository ships LICENSE.md and NOTICE.md at the top level. The web package.json declares the same license identifier.

## Sources

- [concourse/concourse on GitHub](https://github.com/concourse/concourse)
- [License: Apache-2.0](https://github.com/concourse/concourse/blob/master/LICENSE)
- [Project website](https://concourse-ci.org)
- [README](https://github.com/concourse/concourse/blob/master/README.md)
- [Releases](https://github.com/concourse/concourse/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/concourse-concourse