[vito]

You pretty much got it right. That page is still a bit rough; we'll give it some TLC soon.

Workers are just machines running a container management daemon (much like a Docker daemon) and a volume manager (a custom daemon for managing caches and efficient artifact propagation between containers). Not sure how you got to Cloud Foundry though, it's not really related. Garden lives in the Cloud Foundry GitHub organization, as it's also used by Cloud Foundry, but you don't need to know anything about CF to use Concourse.

Concourse supports Linux, Windows, and OS X. You can see an example of this here:

https://ci.concourse.ci/pipelines/main/jobs/fly/builds/2621

[kureimoru]

I will jump in with a question: what about FreeBSD? Can I have a FreeBSD slave / Garden?

[vito]

If someone writes a Garden backend for it, sure. Here's an example of a pretty small backend that delegates to `systemd-nspawn`:

https://github.com/vito/garden-systemd

[zeisss]

Also please add pictures. there is nothing beating a pictures with 3 boxes and arrows :P

[oblio]

Is Windows support on the roadmap?

[vito]

Woops, typo'd in my original comment: it supports Linux, Windows, and OS X. :) Binaries here: http://concourse.ci/downloads.html

[itay]

I've been trying to figure this out from the docs, but how does it support Windows? In the sense that for now (until Server 2016 comes out), you don't really have "container support".

[vito]

Concourse just talks to Garden, it's up to the Garden backend whether or not it actually does containerization. So on Windows it just does the world's worst containerization (cd'ing into a directory), though it at least guarantees that the processes all die.

There's a proper Garden Windows backend in the works which we'll switch to at some point once we better understand it: https://github.com/cloudfoundry/garden-windows