Official Runpod templates
Prefer an official template over building an image. Runpod maintains prebuilt
images for common workloads; deploying one is a create + poll, with no SSH install
step. This skill is the reference for what those images actually are. It does not
manage infrastructure — deploy with runpod-mcp (if connected) or runpodctl.
Terms — "template" vs the Hub
Two different products share the word "Hub", and conflating them derails discovery:
| Term | What it is | Runs as | Discover with |
|---|
| Pod template (this skill) | A saved pod config — image + ports + disk + env. The official ones appear on Console Hub template pages (console.runpod.io/hub/template/<id>
| a pod | runpodctl template list --type official
GET /v2/catalog/templates
|
| Hub repo / listing | A packaged serverless worker (e.g. runpod-workers/worker-comfyui
| serverless | / · MCP / |
Same word, disjoint catalogs:
returns only the serverless worker
and none of the official ComfyUI
pod templates, and
returns no
Hub repos. In the REST v2 catalog, pod vs serverless templates are told apart by each
entry's
flag.
What "official" means, and how to find them
A template is Runpod-maintained when it reports
. Anything else in search
results is community-published: usable, but not covered by this skill and not
version-guaranteed.
bash
runpodctl template list --type official # the whole official set (14 as of 2026-08-25)
runpodctl template search <name> # by name; check isRunpod: true
runpodctl template get <template-id> # image, ports, portsConfig, disk + full readme
returns the template's
readme — the description maintained alongside
the image, and the authoritative answer when it disagrees with this skill. Take image
tags, ports, and env from these commands, not from these files: the templates ship on
their own release train and move faster than this repo. The reference files record the
shape and the gotchas, which is the expensive part to rediscover.
⚠️
is not how you find pod templates — see
Terms.
To hand a user a Console link, use
https://console.runpod.io/hub/template/<template-id>
.
REST v2 has no template search — only slices you filter yourself
REST v2 has no query/search parameter for templates, so every "search" is a client-side
filter over a fetched slice:
| Endpoint | Params | Returns |
|---|
GET /v2/catalog/templates
| source=official|verified|community
| the public catalog slice |
| none | only templates you own |
| — | one template, owned or catalog |
(14) and (3) are fully enumerable; is capped at 100
with pagination explicitly unsupported. A community template past that cap never
enters a slice the API can return, and
runpodctl template search
reads those same
server-side slices — so it has no view past the cap either. If a user names one you
cannot find, ask them for the template id rather than concluding it does not exist.
is a GraphQL/v1 field with
no v2 equivalent — in v2, "official" is the
slice you requested, not a flag on the record.
Catalog entries carry
, which is the reliable way to pick between
CUDA-line variants of the same template — pair it with
runpodctl pod create --min-cuda-version
instead of inferring from the GPU name.
The templates
| Workload | Reference | Deploy walkthrough |
|---|
| ComfyUI — image generation UI at a URL | | golden path 02, variant B |
| PyTorch — general GPU base / dev box (2.1 → 2.9, incl. cluster + ROCm builds) | | golden path 06 |
| Ubuntu — bare 20.04 / 22.04 / 24.04 (CPU category) | TODO | — |
| Network storage file browser (GPU + CPU) | TODO | golden path 07 |
Add a template by adding one file here and one row above. Do not create a new skill
per template — the task shape is identical and every registered skill costs context in
every session.
How to use a template reference
Each file under
answers the same questions in the same order, so an agent
can skim to the one it needs:
- Identity — template name, id, image, upstream source repo.
- Variants — CUDA/arch/GPU-generation splits and which to pick.
- Ports and credentials — what is exposed and any default login.
- Autostart — what is already running on boot, with the exact command.
- Paths — where the app, its config, and its data live (and what a network
volume mount changes).
- Readiness — how long first boot takes and the exact signal for "actually
serving". is never the signal.
- What does not ship — the gap between "booted" and "usable", and how to close
it programmatically rather than by clicking.
- Sizing — container disk and minimum VRAM.
- Version pinning — how to hold a known-good version.
Routing onward — this skill is the hub, not the destination
A user asking about a template rarely wants the reference file itself; they want a
template deployed, fixed, or replaced. Land here, identify which, and hand off:
| The user wants to… | Send them to |
|---|
| Deploy a template end to end | the matching golden path in the table above (index) — live-verified runs with real commands |
| Fix a pod that won't serve ("Running" but URL dead, 404/502) | the template's reference file, §Readiness — then runpod-usage/reference/gotchas.md
|
| Fix a ComfyUI workflow whose models won't download (missing/broken model metadata, imported workflow or PNG) | the skill — it carries the repair scripts. The official ComfyUI templates ship ComfyUI-RunpodDirect, so its automatic-download path applies |
| Add models / files to a running template pod | the template's reference file (§What does not ship), or for generic Hugging Face transfers |
| Customize beyond what the template ships (pinned versions, extra nodes, lighter image) | runpod-usage/reference/building-images.md
|
| A serverless worker, not a pod | not a pod template — Hub workers via / |
Reference files here answer what is in the image; they never duplicate a walkthrough or
a repair procedure — they point at the owner.