Images and builds
A3S Box stores OCI images locally and uses the same image store from the CLI and every native SDK. Pulling or building an image once makes it available to later Sandbox runs.
Pull and inspect an image
Use immutable digests for production automation:
Tags are mutable names. A digest identifies the exact manifest that Box resolved and verified.
Build from a Dockerfile
Given this application:
build and run it locally:
Select another build file with -f:
The builder supports multi-stage builds, content-addressed caching, build
arguments, and selected RUN --mount forms. Unsupported Dockerfile behavior
fails explicitly instead of being ignored.
Tag and publish
Use a registry token with the narrowest required scope. CI systems should pass credentials through their secret store and avoid printing login commands or environment values in logs.
Move images between hosts
Save an image as an OCI archive and load it on another machine:
import creates an image from a root filesystem archive. It is different from
load, which consumes an OCI image archive and preserves image metadata.
Reclaim space
Inspect runtime disk use before deleting data:
image-prune removes images that are no longer referenced according to its
selected policy. For broader cleanup, review the proposed changes before using
a3s-box system-prune.
Build from an SDK
All four SDKs expose typed image builders. This keeps build arguments and tags in application code without parsing human CLI output. Each language guide contains a complete, runnable builder program:
Next step
An image defines the read-only starting point. Continue with Storage and snapshots to choose a writable layer, volume, or snapshot for runtime data. Open the SDK overview when the image build belongs in application code.