Agent machines
The three forms an agent machine can take — a host, a container image, or a Linux virtual machine — and the per-language images the product ships as templates.
An agent machine is a machine the server dispatches work onto. It is a separate decision from where the server runs, and it has three supported forms. A fleet may use all three at once.
| form | what it is | where it fits |
|---|---|---|
| a host | a Linux or macOS machine, running the agent directly | the simplest fleet, and the only form on Solo, where everything is one machine |
| a container image | a disposable machine created from an image, one per run | the Team and Enterprise shape — identical machines, a toolchain per class, nothing carried between runs |
| a Linux virtual machine | a longer-lived Linux machine you manage as capacity | estates that already manage VMs, and every Windows host — see Supported platforms |
⇒ The container form is the one to reach for as a fleet grows past a few machines. A host accumulates: toolchains, caches, whatever the last run left behind. An image does not — every run starts from the same bytes, which is also what makes "it worked on that machine" a question with an answer.
The images the product ships
There is one per language class, plus one whose only job is to measure a host. All six stand on one base, and until recently that was not true — each started from its own language's official image and the operating system came along for the ride, which produced four operating systems across six images and four of the six with no Node at all. Nobody had chosen that; it was inherited.
Every image now carries the same foundation: Debian 13 (trixie), slim · Node 22 · npm ·
ca-certificates · iptables · the agent binary · a declared class · and a final unprivileged user.
| image | what it adds on top | version |
|---|---|---|
dev-node | — | Node and npm are in the base |
dev-ts | TypeScript | tsc 5.9.3, pinned |
dev-python | Python | 3.13.5 |
dev-java | JDK | 21.0.12.1 |
dev-android | JDK | 21.0.12.1 — ⚠ there is no Android SDK, see Android images |
dev-go | Go | go1.26.8 |
probe | — | measuring a machine's capabilities rather than doing work on it |
Why the base carries Node even for classes that are not JavaScript. Three of the four supported vendor CLIs are npm packages, and one of them requires Node 22 or newer in its own manifest. Debian's own Node package is older than that, so an image built on the bare distribution could not run it. Using the official Node image keeps the rule that one base is pinned by digest while giving every class the same Node and the same npm.
Why Go is copied rather than installed from the distribution. Debian trixie ships a Go older than this product's own requirement, so an installed Go would be a toolchain that cannot build what it is meant to build. It is copied from the official Go image on the same Debian, so it stays compatible with the base.
What one base costs you, and what it saves
| distinct layers | all six on one host | |
|---|---|---|
| four unrelated bases, nothing shared | 32 | ≈ 3733 MB |
| one shared base | 17, of which 7 are the base | ≈ 1325 MB |
⇒ about 65 % less for the full set, and the second image you pull on a host costs only its own
delta: dev-node adds nothing, dev-ts about 31 MB, dev-python about 74 MB, dev-go about
341 MB, and dev-java and dev-android share one JDK layer.
⚠ docker images will show these as larger than they cost you, because its per-image number
double-counts shared layers. The figures above are computed from distinct layer digests.
What is NOT in these images
- ⛔ No vendor CLI. A vendor CLI is licensed to you, not to us, so it cannot ship inside an image we publish. Adding one is a single build — Adding a vendor CLI.
- ⛔ No Android SDK — Android images.
- ⛔ No credentials, no seat identity, no policy. Those arrive at run time. An image carrying them would be a secret anyone could pull.
iptables is present, and that is not the same as configured
Every image carries iptables, because the container egress path needs it: the plan is a bridge
network plus a redirect into a door served inside the container's own network namespace, so that
a refused connection can be reported rather than silently dropped.
⛔ Carrying the tool is not installing the rule. The redirect additionally needs a network capability and a privileged init step that installs it and then drops back to the unprivileged user. Measured: as the unprivileged user the tool is present; with the capability granted the rule installs.
⇒ The tool is there and the rule is expressible. ⚠ Nothing composes it for you yet, so until that lands these images behave on the network exactly as they did before — see Egress control.
What is true today, stated plainly
- ⚠ The images are templates, not a published set. Nothing pushes them to a registry today, so a fleet that wants containerised machines builds them from the templates, with the cross-built agent binary for the target architecture in the build context. A registry and published, versioned images are owed — see Infrastructure for how this section marks what is not yet written or shipped.
- ⚠ A container is not the network boundary. Running inside an image bounds the toolchain and the filesystem a session sees; it says nothing about what the session may reach. See Agent security: the whole set for which control covers what, and Egress control for the one that covers the network.
- What confinement a container adds beyond the image is measured per machine, not assumed from the fact that it is a container — see Sandboxing.
Supported platforms
Linux and macOS run natively. Windows is supported virtualized — the server as a container, agent machines as Linux containers or Linux virtual machines.
Adding a vendor CLI to an image
Four ready build files, the three properties they all share, and what each CLI does behind a proxy — because two of the four ignore the variable most people reach for first.