Deployment types
Published deployments
By default,baseten model push creates a published deployment. Its model artifact doesn’t live reload, so a code or configuration change requires another push. Published model deployments support the full set of autoscaling and environment promotion settings.
A published deployment can serve requests through its deployment-specific endpoint without belonging to an environment.
Development deployment
Usebaseten model push --watch for a model or baseten truss chains push --watch for a Chain to create a development deployment. Development deployments support a fast edit-and-reload loop:
- Source changes live reload without another deployment.
- The deployment uses one replica when active and scales to zero when idle.
- The deployment can’t scale beyond one replica or use zero-downtime updates.
Environments and promotion
An environment gives a model a stable endpoint and a reusable set of resource, autoscaling, and promotion settings. The environment points to the deployment that currently serves its traffic.- A deployment doesn’t need an environment to serve requests.
- The production environment exists by default. You can add environments such as staging.
- Promoting a deployment changes which version serves the environment endpoint without changing that endpoint’s URL.
- Promotion can reuse the source deployment or create a new published deployment, depending on the source type and the environment settings.
Rolling deployments
Rolling deployment is an environment promotion strategy, not a deployment type. It incrementally provisions the candidate deployment, shifts traffic, and removes the previous deployment’s replicas. You can pause, resume, cancel, or force-complete the promotion. For more information, see Rolling deployments.Canary deployments (deprecated)
The management API rejects requests that setramp_up_while_promoting to true on a model environment. Enabling rolling deployments on a model environment turns canary promotions off. Chains still support canary promotions.
Deployment metadata
Baseten addresses a deployment by its model ID and deployment ID. Names and labels help people and automation identify deployments. A deployment name is a human-readable identifier and doesn’t change the deployment’s API path. Set it withtruss push --deployment-name, or rename it later with the Baseten CLI or in the Baseten dashboard:
deployment rename.
Deployment labels are JSON key-value metadata for ownership, source control, or CI information.
The dashboard shows a deployment’s effective regional placement. It shows the selected deployment region first, then any regions allowed by the compliance policy. If neither constraint applies, it shows Global.
You can’t change a published deployment’s labels after creation. A later development push that includes labels replaces the development deployment’s labels. A push that omits labels preserves them.