Environments

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: 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.

​

Attaching policies to an environment

You can attach deployment policies to any environment in order to enforce them across all workloads in that environment that are in the scope of the target of the policy.

When no policies are enforced on a type, all options for this type are considered allowed. Workloads are executed using Global Inference Network’s default optimizations.

Read our complete reference for environments.

​

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 of policy (a.k.a OR clause), and INTERSECTION across all types 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)
• T4 only: GPU is T4 (type of policy: gpu)

Then, all workloads deployed in ‘development’ will run necessarily on T4 accelerators, which are 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 allowing to test version B while version A still runs.
2. Once version B is tested and ready, you release 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 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.