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.