Base images
Use a Debian base image for the target architecture:sail.Image.debian_arm64 and debian_amd64 (aliases
debian_arm / debian_amd) pin the image to your local Python version for
@sail.function.
Install Python packages
Install Python dependencies at build time:exec().
Add local files
Copy a single local file into the image:ignore accepts
gitignore-style patterns, or point at an existing ignore file (such as
.gitignore) instead.
Use image files for source code, static assets, and configuration that should
exist before boot. Use Filesystem for runtime inputs,
outputs, logs, and data that changes per Sailbox.
Install system packages
Install Debian packages with apt:Run shell commands
Run shell commands during the image build:Set environment variables
Bake environment variables into Sailboxes created from the image:Create a Sailbox from an image
Pass the image definition toSailbox.create():
Sailbox.create() uploads any local files, builds
the image if it has not already been built, then starts the VM from that image.
In Rust, build_image_definition runs that same upload-and-build pipeline and
returns the built spec to create from.
Build an image ahead of time
Build the image before creating a Sailbox:Build-time boot and start snapshots
As the final stage of the build pipeline, Sail may boot your image once after the build completes and capture a start snapshot. Sailboxes created from the image can then resume from that snapshot instead of cold-booting, which makes first starts as fast as later ones. This is part of the image build contract:- Your image’s first boot can happen at build time, not when the first Sailbox is created. Boot-time initialization (systemd units, init scripts, services configured to start on boot) runs during that build-time boot.
- State generated during the build-time boot may be shared. Anything your boot process writes to disk or leaves in memory becomes part of the start snapshot that every Sailbox created from this image resumes from. Do not generate per-instance identity (machine IDs, cryptographic nonces, cached credentials) during boot and expect it to be unique per Sailbox.
- Per-Sailbox identity is injected at create time. Environment variables, networking, and Sail-managed credentials are applied when each Sailbox is created, after the snapshot resumes, so runtime configuration behaves the same whether or not a start snapshot was used.
- The build-time boot is best-effort: if snapshot capture is skipped or fails, the first Sailbox simply cold-boots exactly as it would have without one.