Environments

Environments provide structured management for deployments, ensuring controlled rollouts, stable endpoints, and autoscaling. They help teams stage, test, and release models without affecting production traffic.

Deployments can be promoted to an environment (e.g., “staging”) to validate outputs before moving to production, allowing for safer model iteration and evaluation.

​

Using Environments to manage deployments

Environments support structured validation before promoting a deployment, including:

• Automated tests & evaluations
• Manual testing in pre-production
• Gradual traffic shifts with canary deployments
• Shadow serving for real-world analysis

Promoting a deployment ensures it inherits environment-specific scaling and monitoring settings, such as:

• Dedicated API endpoint → Predict API Reference
• Autoscaling controls → Scale behavior is managed per environment.
• Traffic ramp-up → Enable canary rollouts.
• Monitoring & Metrics → Export environment metrics.

A production environment operates like any other environment but has restrictions:

• It cannot be deleted unless the entire model is removed.
• You cannot create additional environments named “production.”

​

Creating custom environments

In addition to the standard production environment, you can create as many custom environments as needed. There are two ways to create a custom environment:

1. In the model management page on the Baseten dashboard.
2. Via the create environment endpoint in the model management API.

​

Promoting deployments to environments

When a deployment is promoted, Baseten follows a three-step process:

1. A new deployment is created with a unique deployment ID.
2. The deployment initializes resources and becomes active.
3. The new deployment replaces the existing deployment in that environment.

• If there was no previous deployment, default autoscaling settings are applied.
• If a previous deployment existed, the new one inherits autoscaling settings, and the old deployment is demoted and scales to zero.

​

Promoting a Published Deployment

If a published deployment (not a development deployment) is promoted:

• Its autoscaling settings are updated to match the environment.
• If inactive, it must be activated before promotion.

Previous deployments are demoted but remain in the system, retaining their deployment ID and scaling behavior.

​

Deploying directly to an environment

You can skip development stage and deploy directly to an environment by specifying --environment in truss push:

cd my_model/
truss push --environment {environment_name}

​

Accessing environments in your code

The environment name is available in model.py via the environment keyword argument:

def __init__(self, **kwargs):
    self._environment = kwargs["environment"]

To ensure the environment variable remains updated, enable** “Re-deploy when promoting” **in the UI or via the REST API. This guarantees the environment is fully initialized after a promotion.

​

Deleting environments

Environments can be deleted, except for production. To remove a production deployment, first promote another deployment to production or delete the entire model.

• Deleted environments are removed from the overview but remain in billing history.
• They do not consume resources after deletion.
• API requests to a deleted environment return a 404 error.