Deployments & promotions
How a trained model becomes a live endpoint — and the difference between shared and dedicated serving.
Promotion
Training produces a scored artifact; promotion is the act of putting it into live serving. You promote a specific training of a pipeline:
training (completed, scored) → promote → deployment (live, serving)A deployment is the record of that promotion: which pipeline, which
training, what serving mode, its current status
(initializing → deploying → deployed, or failed), and its usage.
Deployments are managed under one API surface —
/v1/deployments — covering the lifecycle:
promote, check status, scale, retry a failed deploy, unpromote, delete.
Shared vs dedicated serving
Every deployment runs in one of two modes:
| Mode | What it means | When to use it |
|---|---|---|
| Shared | Your model serves from a multi-tenant pool. No infrastructure of your own; scales with the platform. | The default. Most models, most of the time. |
| Dedicated | Your model gets reserved serving capacity you can scale explicitly. | Strict latency needs, heavy traffic, or isolation requirements. |
Foundation-model deployments route to the platform's foundation serving automatically — you promote them the same way and the platform picks the right backend.
Unpromote vs delete
Two different operations, both under /v1/deployments:
- Unpromote gracefully removes a pipeline from live serving. The deployment record stays for history.
- Delete force-removes a specific deployment record and its serving resources. Use it for cleanup, not for routine rollover.
Stability and your integration
A deployment ID is version-pinned: it always serves the exact training it was created from. If you call a deployment URL directly, your results are perfectly reproducible — but the URL dies when that deployment is replaced. The pipeline and goal aliases exist so you can follow the current champion instead.