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
