#Custom Images
Every Template references a container image. Sandbox0 supports two types of images:
| Type | Description | Example |
|---|---|---|
| Public image | Any image from a public registry | python:3.12-slim, node:20-alpine |
| Private image | Your own image pushed to the Sandbox0 registry | my-app:v1.2.3 |
For private images, Sandbox0 provides a built-in registry and a CLI workflow to build and push images securely. Authentication is handled automatically — your images are protected and only accessible to your team.
Using a Public Image#
To use a public image, simply reference it in your template's mainContainer.image field:
yamlspec: mainContainer: image: python:3.12-slim resources: cpu: "0.5" memory: 1Gi pool: minIdle: 2 maxIdle: 10
Using a Private Image#
Private images require a two-step workflow using the s0 CLI:
Step 1 — Build Your Image#
Build a container image from a Dockerfile using your local Docker daemon. You can use either method:
bash# Option 1: Using s0 CLI (recommended for convenience) s0 template image build . -t my-app:v1.2.3 # Option 2: Using docker build directly docker build . -t my-app:v1.2.3
Both commands are equivalent — s0 template image build is a thin wrapper around docker build.
Build options:
| Flag | Description |
|---|---|
-t, --tag | Image name and tag (required) |
-f, --file | Path to Dockerfile (default: Dockerfile) |
--platform | Target platform (e.g., linux/amd64) |
--no-cache | Disable build cache |
--pull | Always pull a newer base image |
bash# Build with a custom Dockerfile s0 template image build . -t my-app:v1.2.3 -f docker/Dockerfile.prod # Build for a specific platform s0 template image build . -t my-app:v1.2.3 --platform linux/amd64 # Full rebuild without cache s0 template image build . -t my-app:v1.2.3 --no-cache
Both methods use your local Docker daemon to build the image. Make sure Docker is running before executing these commands.
Step 2 — Push to the Sandbox0 Registry#
Push the locally built image to the Sandbox0 registry. The CLI automatically retrieves short-lived credentials from the API:
bashs0 template image push my-app:v1.2.3 -t my-app:v1.2.3
| Flag | Description |
|---|---|
-t, --tag | Target image name and tag in the Sandbox0 registry (required) |
The push command:
- Calls
POST /api/v1/registry/credentialsto obtain short-lived credentials - Re-tags the local image with the registry hostname prepended
- Pushes the image using your Docker daemon
Credentials are short-lived and fetched automatically each time you push. You do not need to run docker login manually.
Step 3 — Reference the Pull Image in Your Template#
After s0 template image push, use the Template image reference value in your template spec.
This reference is the in-cluster pull address and may differ from the external push address.
bash$ s0 template image push my-app:v1.2.3 -t my-app:v1.2.3 ... Image pushed successfully: 127.0.0.1:30500/my-app:v1.2.3 Template image reference: registry.sandbox0-system.svc.cluster.local:5000/my-app:v1.2.3
Use that Template image reference value:
yamlspec: mainContainer: image: registry.sandbox0-system.svc.cluster.local:5000/my-app:v1.2.3 resources: cpu: "2" memory: 4Gi pool: minIdle: 2 maxIdle: 10
Then create or update the template:
bashs0 template create --id my-app --spec-file template.yaml # or update an existing template: s0 template update my-app --spec-file template.yaml
Full Workflow Example#
bash# 1. Build the image (either method works) s0 template image build . -t my-app:v1.2.3 # or: docker build . -t my-app:v1.2.3 # 2. Push to Sandbox0 registry s0 template image push my-app:v1.2.3 -t my-app:v1.2.3 # 3. Create the template using "Template image reference" cat > template.yaml << 'EOF' spec: mainContainer: image: registry.sandbox0-system.svc.cluster.local:5000/my-app:v1.2.3 resources: cpu: "2" memory: 4Gi pool: minIdle: 2 maxIdle: 10 EOF s0 template create --id my-app --spec-file template.yaml # 4. Create a sandbox from your template s0 sandbox create --template my-app
Registry Providers (beta)#
Sandbox0 supports multiple container registry backends. The registry provider is configured by the platform operator:
| Provider | Backend | Notes |
|---|---|---|
builtin | Self-hosted Docker Registry v2 | Default. Deployed and managed within the cluster. |
aws | Amazon ECR | Short-lived tokens (12h). Requires region configuration. |
gcp | Google Artifact Registry / GCR | Uses service account credentials. |
azure | Azure Container Registry | Uses ACR credentials. |
aliyun | Alibaba Cloud Container Registry | Uses Aliyun ACR credentials. |
harbor | Harbor | Uses Harbor robot/user credentials from Kubernetes Secret. |
For all providers, the s0 template image push command handles credential retrieval transparently — you always use the same CLI command regardless of the backend.
How Authentication Works#
Sandbox0 handles image pull authentication at the cluster level — you do not need to configure credentials in each template.
The platform operator maintains a cluster-wide imagePullSecret that is automatically injected into every sandbox pod. As a template author, you only need to reference the correct image name — no credential configuration is required in the template spec.
For self-hosted deployments, the builtin registry provider automatically provisions and manages the pull secret. For external registries (ECR, GCP, ACR, Aliyun, Harbor), the platform operator pre-configures the credentials once during cluster setup.
Next Steps#
Warm Pool
Configure minIdle and maxIdle for fast sandbox creation
Configuration
Advanced template settings