When To Build A Template
| Need | Template Strategy |
|---|---|
| Faster sandbox startup | Move repeated package installs into a template. |
| Consistent runtime dependencies | Pin apt, pip, npm, files, and env defaults in the builder. |
| A service should be ready after create | Use start commands and readiness checks. |
| You already have an image or Dockerfile | Build from an image, Dockerfile, or standard base. |
| You need traceable versions | Build with names and tags, then launch by canonical ref. |
Quick Example
Build Model
| Concept | Meaning |
|---|---|
| Builder | The SDK object or Dockerfile/image source that describes the environment. |
| Build | The operation that turns the builder into a reusable template artifact. |
| Template ref | The name, tag, or canonical ref used by Sandbox.create(template=...). |
| Runtime envs | Environment defaults present when sandboxes start from the template. |
| Build envs and secrets | Values available only while the template is built. |
Template Tasks
Quickstart
Build and launch your first reusable sandbox template.
How it works
Understand how template builds turn setup steps into sandbox snapshots.
Base image
Start from standard images, existing templates, custom images, or Dockerfiles.
Defining template
Install packages, copy files, clone repos, run commands, and set envs.
Start and ready commands
Start services automatically and wait for ports, URLs, files, or commands.
Warm pools
Keep ready capacity for a template and choose fallback behavior at create time.
Build
Build, wait, tune resources, and control cache behavior.
Logging
Stream build logs, reconnect, and inspect cache events.