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.

Two different products share the word "Hub", and conflating them derails discovery:

console.runpod.io/hub/template/<id>

runpodctl template list --type official

template search

GET /v2/catalog/templates

runpod-workers/worker-comfyui

runpodctl hub list

hub search

list-hub-repos

deploy-hub-repo

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.

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.

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.

⚠️

runpodctl hub ...

is not how you find pod templates — see Terms.

To hand a user a Console link, use .

REST v2 has no query/search parameter for templates, so every "search" is a client-side filter over a fetched slice:

GET /v2/catalog/templates

source=official|verified|community

official

GET /v2/templates

GET /v2/templates/{id}

official

(14) and

verified

(3) are fully enumerable;

community

is capped at 100 with pagination explicitly unsupported. A community template past that cap never enters a slice the API can return, and 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

allowedCudaVersions

, which is the reliable way to pick between CUDA-line variants of the same template — pair it with instead of inferring from the GPU name.

reference/comfyui.md

reference/pytorch.md

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.

Each file under answers the same questions in the same order, so an agent can skim to the one it needs:

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:

runpod-usage/reference/gotchas.md

runpod-comfyui-models

companion-clis

runpod-usage/reference/building-images.md

FROM

runpodctl

runpod-mcp

Reference files here answer what is in the image; they never duplicate a walkthrough or a repair procedure — they point at the owner.