Base image definitions for Boardwalk hosted runners — the environment your workflow programs and shell steps execute in. Image sources, pinned versions, and the versioning policy are all here and reproducible; SBOMs and vulnerability scan reports publish with every release.
The hosted Boardwalk platform builds its worker images from these bases, pinned by digest, then adds a private runtime layer. That layer is not published, but it carries no secrets-relevant behavior: the base images in this repo define what your code sees at runtime, and you can build and inspect them yourself.
| Label | Image | Docs |
|---|---|---|
boardwalk/linux |
ghcr.io/boardwalk-labs/boardwalk-runner-linux:<version> |
docs/linux.md |
Roadmap, not yet published. A variant ships only once it's a genuinely distinct environment (not a reskin of the base) and the hosted scheduler can route to its label. Until then, a workflow needing more installs it per-run (subject to the run's egress policy) or uses a custom image. Shapes below are intent, not a commitment.
| Label | Intended to add (beyond the base) | Status |
|---|---|---|
boardwalk/linux-node |
A Node-centric toolchain: extra package managers and multiple Node lines, past the base's single Node 24 | Planned |
boardwalk/linux-python |
Pinned multi-version CPython plus a modern installer (uv / poetry), past the base's python3 |
Planned |
A bigger machine is intentionally not a label here: it's the runs_on size selector
({ label: "boardwalk/linux", size: "large" }), a per-run resource override on the same image.
Have a variant you'd actually run? Open a feature request (see CONTRIBUTING.md). A strong proposal names the tools, why a meaningful share of workflows need them, and why they don't belong in the base.
Hosted runners run on a Firecracker microVM substrate, which boots a kernel and an
ext4 rootfs instead of a container. The recipes for both — a pinned minimal guest kernel with
a verified required-capability set, an OCI→ext4 flattener for the runner images above, and a
smoke-boot gate — live in guest/. Same trust story as the container
images: what your code runs inside is defined here and reproducible.
docker build -t boardwalk-runner-linux images/linux
docker run --rm -it boardwalk-runner-linux bash # inspect the runtime environment
# Regenerate the committed environment lock after any image change (CI fails on drift):
scripts/env-manifest.sh boardwalk-runner-linux > images/linux/ENVIRONMENT.lockimages/linux/ENVIRONMENT.lock is the human-reviewable list of pinned OS packages and tools; CI
re-derives it on every PR and fails if it drifts, so an environment change lands as a reviewed diff.
Every release publishes the image digest, an SPDX SBOM, and the vulnerability scan report.
Versioning, scan gates, triage, and deprecation windows are documented in
POLICY.md and SECURITY_TRIAGE.md.
- Not the engine (
boardwalk) — that runs the control plane on your hardware. - Not the self-hosted runner client (
runner) — that executes Boardwalk-scheduled runs on your machines (and can use these images too).
Apache-2.0