Skip to main content
Sailbox images define the root filesystem used to start a VM. Start from a Debian base image, then chain build steps to install dependencies, copy local files, run setup commands, and set environment variables.
Image definitions are immutable values: each builder step gives you a new definition, so you can safely reuse a base image across multiple variants.

Base images

Use a Debian base image for the target architecture:
In Python, 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:
Package installation happens at image build time, before any Sailbox starts. This is usually faster and more reproducible than installing packages in every new VM with exec().

Add local files

Copy a single local file into the image:
Or copy a directory tree:
Remote paths must be absolute POSIX paths. Directory uploads preserve file modes from the local filesystem and skip symlinks. 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:
Build commands run once while the image is prepared. They do not run each time a Sailbox starts.

Set environment variables

Bake environment variables into Sailboxes created from the image:

Create a Sailbox from an image

Pass the image definition to Sailbox.create():
In Python and TypeScript, 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.
Generate anything that must be unique per Sailbox at runtime (for example in your application entrypoint), not during image boot.

Image caching

Sail caches image builds per organization by content. If the base image, build steps, environment variables, and uploaded file contents are unchanged, later Sailboxes can reuse the existing image instead of rebuilding it. A change to any build step or local file content creates a new image.