---

name: vastai-prod-checklist description: >- Analyze readiness and issue a production go/no-go decision for a Vast.ai renter workload using retained evidence for cost, capacity, security, recovery, observability, and teardown. Use when a release needs production approval. Trigger with: "approve Vast.ai production", "run the Vast.ai launch checklist", "is this Vast.ai workload production ready". allowed-tools: Read, Grep, Write, Edit version: 2.0.0 argument-hint: '[release-id-workload-and-slo]' model: inherit effort: high license: MIT author: Jeremy Longshore jeremy@intentsolutions.io tags:

• saas
• vastai
• production
• readiness
• governance compatibility: 'Requires an immutable release candidate, approved Vast.ai account, workload SLOs, security policy, and rollback owner.'

---

Vast.ai Production Go/No-Go

Overview

Production approval is an evidence bundle, not a list of optimistic assertions. Every gate needs an owner, artifact, and expiry; any failed critical gate yields NO-GO.

Prerequisites

• Release ID, image digest, dataset/model identity, and expected traffic or job profile
• Capacity, latency, reliability, recovery, security, and spend objectives
• Named incident, billing, data-recovery, and teardown owners

Instructions

Step 1: Verify account and permissions

Confirm account/team context, positive balance or approved autobilling, least-privilege keys, audit visibility, and no credential in release artifacts.

Step 2: Verify capacity policy

Demonstrate compliant offers or Serverless worker capacity across required GPU, VRAM, geography, reliability, and price constraints.

Step 3: Verify immutable execution

Pin image/template/model identity and prove startup, health, output contract, and workload-specific acceptance on a canary.

Step 4: Verify recovery

Restore from an external checkpoint or roll back a Serverless template. Prove that stop, outbid, offline, expiry, and zero-balance paths have owners.

Step 5: Verify operations

Show bounded retries, terminal-state handling, logs/metrics, signed webhook or polling coverage, cost alarms, and escalation contacts.

Step 6: Issue the decision

Record PASS, FAIL, owner, evidence URI, and expiry for each gate. Launch only on GO; retain the exact rollback and cleanup commands.

Authentication

Production keys must be named and scoped by function. Separate billing, team administration, deployment, workload storage, and monitoring authority.

Tool Discipline

Use Read and Grep to inspect manifests, configuration, provider output, and existing tests before proposing a mutation. Use Write or Edit only for the approved plan, implementation, test, or redacted receipt; do not create, update, destroy, or fund Vast.ai resources without explicit operator approval.

Output

• Per-gate PASS/FAIL matrix with evidence and expiry
• GO or NO-GO decision with accepted residual risks
• Rollback, incident, billing, and teardown owner receipt

Return release ID, account context, immutable identities, gate results, decision, approvers, expiry, and rollback target.

Examples

A Serverless model release receives GO only after canary output parity, bounded scale testing, signed webhook acceptance, cost thresholds, and reverse rolling-update evidence are attached.

Error Handling

Failure	Response
Critical evidence is missing	Issue NO-GO; an owner assertion is not a substitute.
Offer capacity is temporarily absent	Delay or use an approved alternate profile; do not weaken policy silently.
Rollback was not exercised	Run it on the canary before production approval.
Billing owner is unavailable	Issue NO-GO because zero balance can stop workloads and endanger data.

Resources

• First-party source notes
• Vast.ai pricing
• Manage instances
• Notification webhooks