# Deployment lifecycle

Canonical: https://savrn.com/cloud/docs/inference-deployments

SAVRN Cloud · Coming soon. Public documentation and a browser simulation are available; connected services are not yet available.

A SAVRN Cloud deployment record connects a model configuration to a placement and an observed lifecycle state. The preview lets you rehearse readiness, draining, restart and deletion, while the guide explains what those transitions must prove when actual resources and billing are involved.

**SAVRN Cloud · Coming soon · Public preview · Browser-local simulation · No live compute or payments**

## Create a local deployment record

Open [Deployments](https://savrn.com/cloud/console/#/deployments), or follow **Create a demo deployment** from a model detail. Choose a demonstration model and the placement options exposed by the form. Review the configuration before submitting. The application creates a browser-local resource record, not a cloud allocation.

Use **Overview**, **Configuration** and **Logs** in the deployment detail. **Drain requests** moves it to drained while retaining allocation. **Restart runtime** or **Resume / restart** returns it to ready. **Delete allocation** opens exact-name confirmation; **Delete local allocation** records deleted and retains logs. Every transition is simulated. Inspect related [Operations](https://savrn.com/cloud/console/#/operations) and [Capacity](https://savrn.com/cloud/console/#/capacity).

## Follow identity across records

A deployment links to a model ID, provider label, region, GPU description, creation time and displayed rate. Candidate promotion may add a relationship to a trained-artifact fixture. Preserve these relationships when exporting or reviewing the demonstration.

**Run demo health check**, **Simulate 1 hour**, **Edit ceiling** and **Export manifest** exercise observability and accounting controls locally. None affects a supplier bill.

## Before connected services launch

A real controller must allocate the selected resource, verify the intended runtime and model, pass readiness checks, publish its capacity and reconcile lifecycle state. Draining, stopping and destroying have different effects. Confirm which action ends billing and what happens to storage. A successful create request is not proof of readiness. Promotion and rollback require observed serving identity; an approval record alone cannot enact either operation.