Skip to main content
Aspect publishes a set of pre-built machine images for Workflows CI runners, called starter images. They’re open source, built with Packer, and the scripts that produce them live in aspect-build/workflows-images. Starter images let you stand up Workflows without first building an image of your own, which suits a trial or a first deployment. For production, we recommend building and maintaining your own image, so you control the OS and package versions and your security patching cadence. See Custom machine images, and use the starter image Packer scripts as a reference.

Current release

The latest starter image version is 20260916-0. Images are versioned YYYYMMDD-N, where N is the build number for that day. A new version is published when base images are refreshed or packages change; versions are immutable, so pin one and bump it deliberately.
Debian 11 reached end of life on 2026-08-31 and has no starter images from 20260916-0 on. Previously published Debian 11 images still exist but receive no updates. Use Debian 12 or 13.

Image names

Every starter image is named:
For example, aspect-workflows-ubuntu-2404-kitchen-sink-amd64-20260916-0. The architecture is amd64 or arm64. GCP images additionally belong to an image family named aspect-workflows-<distro>-<variant>-<arch>, with no version suffix. Resolving the family always gives you the newest image in it.

Distributions

Every distribution below is published for both amd64 and arm64, in every variant.

Variants

Each variant builds on minimal, so pick the smallest one that satisfies your build.

minimal

The Workflows dependencies and a small set of recommended extras:
  • fuse, required by the high-performance remote cache configuration.
  • git and git-lfs, to fetch source and support repositories using LFS.
  • rsync and rsyslog, used by runner bootstrap and system logging.
  • mdadm, for RAID 0 across multiple NVMe drives.
  • patch and zip, used by some rulesets, package managers, and Bazel’s undeclared test outputs.
  • The cloud monitoring agent: the CloudWatch agent on AWS, and the Ops Agent with google-osconfig-agent on GCP. AWS Debian images also install the SSM agent.
Packages already present in a base image aren’t reinstalled, so the exact package list differs slightly per distribution.

gcc

Everything in minimal, plus g++ and the matching libstdc++ development package for that distribution’s default compiler. On Amazon Linux this is gcc, gcc-c++ and libstdc++-devel.

docker

Everything in minimal, plus Docker CE: docker-ce, docker-ce-cli, containerd.io, and the Buildx and Compose plugins. Amazon Linux uses its own docker package. The Docker service is enabled, so it starts on boot.

kitchen-sink

Everything in docker and gcc, plus the build and test tooling most non-hermetic builds reach for:
  • Build tools: build-essential, clang, cmake, make, jq, yq, moreutils.
  • Development headers: libssl-dev, zlib1g-dev, libyaml-dev, libzstd1.
  • Headless browser and GUI test libraries: GTK 2 and 3, ATK, NSS, CUPS, ALSA, libxss1, libxtst6, plus Xvfb and xauth for a virtual display.
chromium and Node.js are currently installed only on the AWS Ubuntu 24.04 and Ubuntu 26.04 kitchen-sink images. If you need them on another kitchen-sink image, contact support and we’ll add them.
The exact package set varies by distribution, since package names differ across Debian, Ubuntu and Amazon Linux releases. The authoritative list for any image is the install_packages block in its Packer file, for example aws/ubuntu-2404/kitchen-sink.pkr.hcl.
You may also see images with a custom-0 variant on Ubuntu 24.04. They aren’t starter images and can change without notice. Use one of the variants above.

Find an image

AWS

List every starter image in the current release, in the region you deploy to:
Narrow it to one distribution and variant, and take the most recent version:
AMIs are region-scoped, so query the region your runners launch in. If your region isn’t in the published list above, copy the AMI into it with aws ec2 copy-image.

GCP

List every starter image in the current release:
Resolve the newest image in a family, which is the most reliable way to find the current version of one distribution and variant:

Use an image in Terraform

On AWS, look the AMI up by name and pass its ID to the runner group:
images.tf
On GCP, reference the image by name in the aspect-workflows-images project:
images.tf
Then set image_id on the resource_types entry your runner groups reference (through their resource_type) to data.aws_ami.runner_image.id or data.google_compute_image.runner_image.id. See and .
Pin a specific version rather than resolving the newest image. Runner instances pick up a new image only when they’re replaced, so an unpinned lookup makes the image your runners boot depend on when an instance last recycled.

Keeping up to date

New versions are announced by tag in aspect-build/workflows-images. When a version fixes a security issue, the relevant security advisory names the first version that carries the fix. To move a deployment, change the version in your images.tf and re-apply. Existing runner instances continue on the old image until they are replaced, so trigger an instance refresh if you need the change to take effect immediately.