Deploy Vast.ai integrations to Vercel, Fly.io, and Cloud Run platforms. Use when deploying Vast.ai-powered applications to production, configuring platform-specific secrets, or setting up deployment...
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.
Record all non-secret template settings, image digest, on-start behavior, exposed ports, disk, label, and required GPU/host constraints.
Build and scan the image, run local contract tests, and launch a disposable canary from the exact template hash.
Bound state polling, resolve current endpoints, check process and GPU health, and execute a representative request or batch assertion.
Create or update the production instance only after canary acceptance. Persist resource IDs and externalize important data before traffic or work begins.
Track state, logs, request/job outcome, cost, disk, and checkpoint health through the acceptance window.
On regression, route work to the last-known-good template or recreate from it; copy evidence and destroy rejected or superseded instances.
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.
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.
Return release, image/template identities, offer and instance IDs, health result, acceptance window, decision, and cleanup status.
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.
| 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. |