Skip to main content
A deployment is a version of your model running on Baseten with its own API endpoint. This page explains how deployments, environments, resources, autoscaling, and CI/CD fit together. To create, promote, scale, or deactivate a deployment, see Manage deployments.

Deployments

A deployment runs one version of your model on a selected instance type. Each truss push creates a deployment. Multiple deployments of the same model can run at once, allowing you to test a new version without changing production traffic. Deactivate a deployment to stop serving and billing, or delete it when you no longer need it. For rapid iteration, use truss push --watch to create a development deployment, a mutable instance that live-reloads as you edit your model code. Development deployments can’t be promoted to an environment. Baseten deployments dashboard showing multiple model versions

Closed-source models

Some models on Baseten are distributed by model labs that keep their weights and implementation private. You can deploy, scale, promote, and monitor one like any other deployment. The model lab controls operations that expose or change the model. For details, see Customer availability and artifact access. These deployments also run without outbound network access. The deployment uses the instance type published with the listing, and the customer cannot change it after adoption.

Environments

Environments provide stable endpoints that persist as you release new deployments. A typical setup uses one environment for testing and another for production traffic. Each environment has its own endpoint, autoscaling settings, and metrics. Promoting a deployment moves the environment’s traffic to that version without changing the URL called by your application. Deployment environments with development and production endpoints

Resources

Every deployment runs on an instance type that defines its GPU, CPU, and memory. Set the instance type in config.yaml, or change it for a published deployment in the Baseten dashboard. Select an instance based on the model’s memory requirements, latency target, and expected traffic. Resource configuration showing GPU instance type selection

Autoscaling

Autoscaling adjusts the number of replicas as request load changes. Configure the minimum and maximum replicas, concurrency target, and scale-down delay. A deployment can scale to zero when idle, but the next request must wait for a replica to start. See Cold starts for ways to reduce that delay. Autoscaling configuration with replica count and concurrency settings For the mechanics of how the autoscaler tracks in-flight requests and adjusts replicas, see How Baseten works. For engine-specific autoscaling settings (BEI and Engine-Builder-LLM), see Autoscaling engines.

Request lifecycle

Before your model code runs, each request passes through authentication, routing, and replica selection. See Request lifecycle to understand queuing, load shedding, timeouts, and HTTP status codes.

CI/CD

Use the Truss Push GitHub Action to deploy a model from a Git repository, validate it with a predict request, and optionally promote it to production. Configure the workflow to run for selected branches, pushes, or pull requests.