Choosing a template
A template is the recipe your instance boots from: the image and tag, the launch mode, environment variables, ports, an optional on-start script, and the machine constraints the recipe needs. You pick one on the deploy page, right after you pick hardware.
System templates and your own
| Curated (system) | Private | Public | |
|---|---|---|---|
| Who maintains it | Superheat | Your organization | Its owning organization |
| Who can see it | Everyone | Your organization only | Everyone |
| Who can edit it | Nobody — immutable through the API | Its owning organization | Its owning organization |
| Badge on the card | Curated | A lock icon | Public |
Start with a curated template. They are the ones the deploy picker offers by default, and most carry an [Automatic] tag — shown as an Automatic badge — which resolves at launch to an image tag matching the CUDA version of the machine you picked.
Build your own when you need a specific image, your own environment variables, extra ports, or an on-start script. Duplicate on any template copies it into your organization as a private template you can edit — secret values and private registry credentials are not copied across organizations, so you re-enter your own. See Create a template.
The tabs
The Templates page splits the gallery into five tabs.
| Tab | What it lists | Ordering |
|---|---|---|
| Recommended | Curated Superheat templates | The curated order, then name |
| My Templates | Templates your organization owns, private and public | Most recently edited first |
| My Recent | Templates your organization has already deployed from | Most recently launched first |
| Popular | Curated and public templates | Launch count, highest first |
| Serverless | Nothing yet — a placeholder for auto-scaling, pay-per-request endpoints | — |
Below the tabs sit a search box, which matches on name, description and image, and a row of facet chips: SSH, Jupyter, args and VM for launch mode, and CUDA floors taken from the templates currently listed, such as CUDA 12.4. Chips toggle; clicking an active chip clears it. The Serverless tab hides them, since there is nothing to filter.
Each card carries the template's name, its image reference, a launch-mode badge, derived badges such as CUDA 12.4, Automatic or ARM, and a launch count. Opening a card shows the full recipe — image, Jupyter settings, environment, ports, arguments, on-start script, machine constraints and readme. Environment values marked secret stay masked unless your organization owns the template. A tab shows up to 100 templates at first; Load more at the bottom fetches the next page.
On Superheat CN every curated template's image reference points at Alibaba Cloud ACR, for example superheat-cn-registry.cn-shanghai.cr.aliyuncs.com/superheat/pytorch, and that is the reference the card and the detail view show. A duplicate keeps the same reference. See Images on Superheat CN.
Getting a template onto the deploy page
The deploy page's picker lists the curated templates, so a private template of your own will not appear there on its own. Launch it from the gallery instead: press Launch on the card or in its detail dialog, pick hardware in the marketplace, and the template travels with you. It is pinned to the front of the picker and preselected, as long as it fits the machine you chose.
How the compatibility check works
Once an offer is chosen, every template in the picker is checked against that machine. Incompatible ones are dimmed and cannot be clicked; hovering one shows the reason. The page preselects the template you launched from the gallery if it passes, otherwise the first template that does.
If nothing in the picker fits the machine, an error panel appears next to the deploy button titled "Template won’t run on this machine", followed by the reason and "Pick a compatible template or a different GPU." The deploy button stays disabled until you do.
The checks run in this order, and the first failure is the reason you see.
| Check | Fails when | What you are told |
|---|---|---|
| Availability | The template is flagged coming soon | This template isn’t available to launch yet. |
| Architecture | The template declares an architecture other than amd64/x86_64 | Needs ARM (arm64) hardware; Superheat hosts are x86_64. |
| Virtualization | Launch mode is vm, or the template requires a VM-capable host, and the offer is not one | This machine is not VM-capable. |
| CUDA (too old) | The template's cuda_min is above the machine's Max CUDA | Needs CUDA ≥ 12.4; this machine has 12.1. |
| CUDA (too new) | The template's cuda_max is below the machine's Max CUDA | Pins an older CUDA stack (supports up to 12.4); this machine has 12.8. |
| VRAM | The template's minimum VRAM is above the offer's VRAM per card | Needs ≥ 48 GB VRAM; this machine has 24 GB. |
Two details worth knowing:
- The VRAM check is against VRAM per card, not the slice total. A 4× slice of 24 GB cards does not satisfy a 48 GB requirement.
- A template's recommended disk size is a suggestion, not a constraint. It appears among the machine constraints on the template as "N GB disk suggested", the compatibility check ignores it, and the deploy page's disk slider does not adopt it — the slider starts at its own default.
The check is a convenience, not the enforcement point. The API checks four of these rules on the server too and refuses with a 422, whether the request came from the console or from your own code: coming soon is TEMPLATE_COMING_SOON, architecture is TEMPLATE_ARCH_UNSUPPORTED, virtualization (the vm launch mode) is OFFER_NOT_VM_CAPABLE, and CUDA too new is TEMPLATE_CUDA_TOO_NEW. The API does not check CUDA too old or VRAM at deploy; both go to the scheduler as placement requirements instead. On a machine that does not meet them the deploy returns 201, but the instance never starts and ends in error (not billed). See Error codes.
The ssh and jupyter launch modes carry one further requirement that is not part of this check: the image has to derive from the Superheat base image, because a stock image has no SSH server and no JupyterLab to start. On Superheat CN that means a reference in the superheat/ namespace on ACR, which the curated templates already use. args and vm run any image. See Launch modes and Base image.
What "coming soon" means
Some templates are published before their execution path exists. Others are held back until they can require the instance access token on their public port: Ollama, InvokeAI, LLaMA-Factory and vLLM, whose servers cannot yet refuse a request without it. Both kinds carry a Coming soon badge on the card, and the compatibility check refuses them on every machine, so they can never reach a deploy. On the card the Launch button is disabled with the tooltip "Execution ships in a later release."; in the detail dialog the same button is disabled and reads Coming soon (即将推出).
On Superheat CN, curated templates from NVIDIA NGC (nvcr.io) are flagged coming soon as well — Triton Inference Server and RAPIDS, for example: NGC images are not copied to Alibaba Cloud ACR. See Images on Superheat CN.
The Serverless tab is the same idea at gallery scale: it is a placeholder for a feature still being built and always comes back empty. Nothing about it is filterable or launchable yet.
Coming-soon templates are still readable — open one to inspect its image, environment and ports — and you can duplicate one into your organization. A duplicate keeps the flag, so the copy will not launch either.