Immutable Vast.ai Instance Deployment
Overview
Make the deployment reproducible outside the console. Bind release bytes to an immutable image and versioned template hash, launch a canary under policy, validate service and GPU health, then promote or destroy.
Prerequisites
- Release commit, image digest, template hash, ports, environment names, and startup contract
- Offer policy, health checks, artifact/checkpoint destinations, and maximum rollout time
- Last-known-good image/template plus rollback and teardown owners
Instructions
Step 1: Freeze the deployment manifest
Record all non-secret template settings, image digest, on-start behavior, exposed ports, disk, label, and required GPU/host constraints.
Step 2: Validate outside production
Build and scan the image, run local contract tests, and launch a disposable canary from the exact template hash.
Step 3: Verify readiness
Bound state polling, resolve current endpoints, check process and GPU health, and execute a representative request or batch assertion.
Step 4: Promote deliberately
Create or update the production instance only after canary acceptance. Persist resource IDs and externalize important data before traffic or work begins.
Step 5: Observe the release
Track state, logs, request/job outcome, cost, disk, and checkpoint health through the acceptance window.
Step 6: Roll back or close
On regression, route work to the last-known-good template or recreate from it; copy evidence and destroy rejected or superseded instances.
Authentication
Give deployment automation only search, template, and instance permissions it needs. Keep registry, model, and storage secrets in approved runtime variables and out of template descriptions and logs.
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
- Versioned deployment manifest and immutable identities
- Canary and production health/acceptance evidence
- Promotion, rollback, and superseded-resource cleanup receipt
Return release, image/template identities, offer and instance IDs, health result, acceptance window, decision, and cleanup status.
Examples
A model API is launched from a pinned template hash and image digest, passes GPU and request canaries, then replaces the previous instance; the rejected candidate is destroyed and the old template remains recorded for rollback.
Error Handling
| Failure | Response |
|---|---|
| Template resolves different bytes | Stop and pin a new immutable hash before provisioning. |
| Health passes but workload assertion fails | Reject the release and retain the last-known-good service. |
| Rollback data is only on local disk | Copy it externally before destructive recovery if the incident permits. |
| Superseded instance remains | Treat it as a cost leak and complete or escalate teardown. |