pod-deploy

Pod deploy

You provision one Pod the user asked for and hand back exactly how to reach it. Before creating anything you confirm the GPU class has real stock in the data center you place into: the create call places exactly the type you ask for, never falls back to another GPU, and answers 400 when that type cannot be placed. You pick a sensible image and the ports the workload needs (an app UI, Jupyter, SSH), and you return the Runpod proxy URL in its working form. For a training Pod you co-locate a network volume so checkpoints outlive the Pod's container disk.

Creating a Pod is billable. State the hourly cost before you create it. Diagnosing or recovering a Pod that already exists is a different job: that is pod-doctor.

Required capabilities

Named as capabilities; the tool serving each one on this server is in the tool binding below. This skill reads stock before it creates, and creates only the Pod the user asked for.

• Read GPU stock per data center, with the CUDA versions that have capacity when a CUDA floor matters: confirm the class is available before creating (delegate the fuller catalog read to discovery).
• Create a network volume: checkpoint durability for training (delegate the CRUD hygiene to lifecycle-crud).
• Create a Pod (image, GPU or CPU, disk, ports, env, data center, mounts).
• Inspect a Pod: read back its status, exposed ports, and the proxy/public address.
• List Pods: resolve "which Pod" and confirm what already exists.
• Read a Pod's boot logs: confirm the app came up on the port before handing back a URL.
• Stop / terminate a Pod: create-then-pause, and cleanup when the user asks for it.

Phase 1 — confirm stock and shape the Pod

• Read GPU availability for the class the workload needs before creating. include:["AVAILABILITY"] together with product:["POD"] (the two go together, and stock differs by product) carries the per-data-center picture, so the data center you place into is read, not assumed. If the class has no stock there, say so and offer another class or data center; do not create into an unavailable class.
• Pick the image for the use: an interactive app (e.g. a ComfyUI or PyTorch image) for dev, a CUDA/PyTorch base for training. Match the image's CUDA to what the GPU class supports, and pin it as a floor on the create: gpu.minCudaVersion at the image's CUDA line (12.8 for a CUDA 12 image; 13.0 only for an image built on CUDA 13), so the Pod lands on a host whose driver supports the image. A template's allowedCudaVersions seeds the floor; an explicit gpu field on the create replaces the seed, and the availability read's cudaVersions says whether that floor has stock.
• The image comes from this session's reads, not memory. For a named app (ComfyUI, Jupyter, a specific stack), resolve the image from the templates / Hub-repos read you just made and cite that source when you pick it. An image already running on the account (visible in a list-pods read) is also a session-read source worth checking when the catalog comes up empty; cite the pod you saw it on. Only when the catalog has no match may you fall back to a well-known public image, and then say so explicitly in the answer. A from-memory image tag is how you get a stale image that crash-loops on boot. Runpod publishes no :latest tags, so pin an exact tag; for GPU work prefer the runpod/pytorch images over runpod/base.
• Decide the ports from the workload: the app's own port over HTTP for a web UI, 8888/http for Jupyter, 22/tcp for direct SSH. SSH also needs startSsh: true at create and a key registered on the account (check get-ssh-keys first); without both the Pod has no SSH access whatever its ports. Only expose what the user needs to reach.
• State the cost. Quote the GPU's hourly rate from the catalog read before creating. A running Pod bills whether or not the user is using it.