Skip to main content
A template is a snapshot of a Linux filesystem (base image, build steps, and optionally a long-running process) that sandboxes boot from. Templates let you pre-install dependencies once and launch identically configured sandboxes in seconds. Every sandbox is created from a template. If you don’t specify one, Superserve defaults to superserve/base.

​
System templates

Curated by Superserve and available to every team. Identified by the superserve/ name prefix (which is reserved — team templates can’t use it). Each is built from an OCI base image plus a few apt / pip / npm steps. Every template ships ca-certificates, curl, and git — the column below lists only what each adds on top. A sandbox inherits its VM shape (vCPU, memory, disk) from the template it boots from — see BuildSpec reference for the limits.

​
Team templates

Team-owned templates let you bake in team-specific dependencies (e.g. my-python-env with scientific libs pre-installed). They’re created via Template.create() and referenced by name. Team template names cannot start with superserve/; that prefix is reserved. Names are unique per team among non-deleted templates and are released for reuse the moment a template is deleted.

​
Names vs UUIDs

When booting a sandbox, Sandbox.create({ fromTemplate }) accepts either the template’s name (my-python-env) or its UUID. Names are more readable; UUIDs are stable across rename/delete.