Templates & images

Anatomy of a template

image:  powergpu/vllm:0.8            # pinned tag, rebuilt on upstream releases
ports:  8000/http                    # exposed + TLS-terminated for you
mounts: /root/.cache/huggingface     # survives restarts on the instance disk
env:    MODEL=…                      # anything here is overridable at deploy

At deploy you can override every field — add env vars, open more ports, change the disk size. Overrides are saved with the instance, so start/stop keeps them.

Environment variables

Set at deploy (console form, --env flags, or API env map). Secrets note: env values are stored encrypted and never appear in logs, but for long-lived credentials prefer fetching them at boot from your own store.

Your own Docker image

The Docker template accepts any image reference:

powergpu launch --gpu l40s \
  --image ghcr.io/acme/trainer:v14 \
  --ports 8080 --disk 100 \
  --env WANDB_API_KEY=…

• The NVIDIA runtime is injected — do not bundle drivers; CUDA userspace in the image is fine.
• Private registries: add credentials once under Settings; they are stored encrypted per-account and used only to pull.
• Entry behaviour: your ENTRYPOINT/CMD runs as-is. No wrapper, no agent inside your container.

Versioning

Template tags are immutable: a redeploy of powergpu/pytorch:2.6-cuda12.8 is byte-identical next month. New upstream releases arrive as new tags; the console highlights when a newer tag exists but never switches you silently.

Image caching & cold starts

Maintained templates are pre-pulled on most hosts — that is the ~30-second deploy. Custom images pull on first use on a given machine (network-speed dependent), then cache. Very large images benefit from slimming: each GB is roughly 1–3 s of extra first-boot.