> ## Documentation Index
> Fetch the complete documentation index at: https://blaxel-pm-2441-firewall.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Environments

> Define environments to enforce consistent deployment strategies, isolation, and promotion workflows across your entire Blaxel workspace.

**Environments** are logical entities that provide a structured framework for managing the lifecycle of your applications across various stages of development, testing, and production.

By bundling deployment policies, environments ensure that all workloads deployed within them adhere to consistent guidelines — promoting predictability, control, and quality throughout your organization.

Currently, Blaxel provides all workspaces with two different environments: **production** and **development**.

* They are created without any [policy](/Model-Governance/Policies): by default, workloads deployed in these environments won’t have any deployment restrictions.
* They allow for a development/production release lifecycle: each environment provides a specific inference endpoint for workloads deployed within it.

<Info>Please reach out to us at [support@blaxel.ai](mailto:support@blaxel.ai) if you would like to use more than two environments.</Info>

## **Attaching policies to an environment**

You can attach [deployment policies](/Model-Governance/Policies) to any environment in order to enforce them across all workloads in that environment that are in the scope of the [target](/Model-Governance/Policies) of the policy.

When no policies are enforced on a type, all options for this type are considered allowed. Workloads are executed using [Global Agentics Network](../Infrastructure/Global-Inference-Network)’s default optimizations.

Read our [complete reference for environments](https://docs.blaxel.ai/api-reference/environments/create-or-update-environment).

### Attaching multiple policies to an environment

When attaching multiple policies to the same environment, it is important to understand the resulting effect to avoid any error.

Their combined effect is the **UNION** of all of their effects for the same [type](/Model-Governance/Policies) of policy (a.k.a *OR* clause), and **INTERSECTION** across all [types](/Model-Governance/Policies) of policies (a.k.a *AND* clause).

For example, let’s say you attach the following three policies on environment ‘development’:

* US only: Country is United States *(type of policy: location)*
* Asia only: Continent is Asia *(type of policy: location)*
  Then, all workloads deployed in ‘development’ will run on **any** location that is either in the US or in any country in Asia.

## **Deploying workloads to an environment**

### Deploying a workload

When deploying a function, agent or model API, you can choose an environment on which to deploy it. When an object is deployed in an environment, this produces a “*deployment*” of this object.

If you don’t specify an environment when deploying a workload, the workload is deployed in the *production* environment by default.

### Rolling out a deployment to a new environment

Deployments can be **released** to a new environment. This replaces the deployment that was initially on the new target environment, and keeps the origin deployment intact.

For example, for Agent XYZ:

1. Let’s say you have version A of the agent running on the *production* environment (this is the production deployment), and version B of the agent running on the *development* environment (this is the development deployment). Each version can be called through the [respective agent deployment endpoint](../Agents/Query-agents) allowing to test version B while version A still runs.
2. Once version B is tested and ready, you [release](../Models/Model-deployment) the *development deployment* on the *production* environment.
3. Now: version B runs on the *production* environment, and version B also runs on the *development* environment. Version A can no longer be called.
4. You [replace](../Models/Model-deployment) the *development* deployment with version C of the agent.
5. Now: version B runs on the *production* environment, and version C runs on the *development* environment.