Agent machines

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 forms. A fleet may use all three at once.

⇒ The container form is the one to reach for as a fleet grows. 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.

⚠ A container run is placed on the local machine only. A container run on a machine reached over ssh is refused in this release (Sandboxing).

The images the product ships

There is one per language class, plus one whose only job is to measure a host. The six class images stand on one base: Debian 13 (trixie), slim · Node 22 · npm · ca-certificates · iptables · iproute2 · the agent binary · a declared class · and a final unprivileged user. The base image is pinned by digest.

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.

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 saves you. The second image you pull on a host costs only its own layers: dev-node adds nothing, dev-java and dev-android share one JDK layer, and the rest add only their toolchain. ⚠ docker images will show these as larger than they cost you, because its per-image number double-counts shared layers.

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 there for the container bridge

Every class image carries iptables and iproute2, because the container's network wall needs them: 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. The engine composes that wall itself on a local container run when the host's measured record allows it (How egress control works).

⚠ The container bridge is built and chosen automatically, and it has not been exercised with a full agent turn. Treat it as unproven (Egress limits).

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 container is not the network boundary by itself. Running inside an image bounds the toolchain and the filesystem a session sees; what the session may reach is Egress control. See Agent security: the whole set for which control covers what.
• What confinement a container adds beyond the image is measured per machine, not assumed from the fact that it is a container — see Sandboxing.