Runtime Images

Runtime images are how teams package the execution environment the runtime will use for work.

The image is part of the execution contract. It shapes what tools, system libraries, certificates, and base utilities are available once work reaches the runtime.

Common Modes

• pulled images from a registry such as GHCR for normal product usage
• local builds from a checked-out agirunner-runtime repository when you are actively changing the runtime
• digest-pinned release images for safer deployment

Recommendation

The top-level agirunner stack reads a configurable RUNTIME_IMAGE value from .env.

Today that default is ghcr.io/agirunner/agirunner-runtime:latest, so the public product bring-up path can stay inside the agirunner repo alone.

That .env value is the bootstrap/default path, not a permanent lock. Fresh stacks seed their first runtime image choice from RUNTIME_IMAGE, then operators can override or rotate runtime image settings later from the dashboard or API.

latest currently tracks the newest published prerelease or release in the runtime repo. Teams that want tighter control can replace it with an exact prerelease tag such as 0.1.0-alpha.1 or with a pinned digest.

Why This Matters

If the image drifts, the behavior of real task execution can drift with it. Agirunner treats the image as an explicit part of runtime posture, not as an invisible implementation detail.

How It Connects To The Rest Of The System

Runtime images sit underneath several more visible execution surfaces:

• Environments is where operators define the execution profiles that point at these images
• Runtime Operations explains how image posture fits into the broader runtime operating model
• Customization And Images covers the runtime-side image strategy in more detail

This page is the deployment view of the same thing the dashboard later exposes as execution environments and runtime posture.