Skip to content
VB-OSVB-OSVB-OS Docs

Environments in VB-OS

Environments provide isolation within a project. They separate development, staging, and production workloads so boundary changes can be tested before reaching production.

Environment Model

Section titled “Environment Model”

Each environment has:

  • Name: a unique identifier within the project (e.g., development, staging, production)
  • Type: one of DEVELOPMENT, STAGING, PRODUCTION, or CUSTOM, which determines which boundary version statuses are deployable
  • Status: ACTIVE or DEACTIVATED
  • Active deployments: one active deployment per boundary currently serving evaluations
  • API keys: scoped to this environment
  • Evaluation history: all evaluations run in this environment

Approval Configuration

Section titled “Approval Configuration”

Environments can require approval before deployments become active:

  • approval_required: when enabled, new deployments enter PENDING_APPROVAL status and must be explicitly approved
  • minimum_approvers: the number of approvals required before a deployment can be activated
  • self_approval_allowed: whether the user who created the deployment can also approve it

Environment Types and Deployable Versions

Section titled “Environment Types and Deployable Versions”

The environment type determines which boundary version statuses can be deployed:

  • DEVELOPMENT: allows DRAFT, UNDER_REVIEW, and APPROVED boundary versions
  • STAGING: allows only APPROVED boundary versions
  • PRODUCTION: allows only APPROVED boundary versions
  • CUSTOM: configurable per environment

This ensures that only fully approved boundaries reach staging and production environments.

Isolation

Section titled “Isolation”

Environments are fully isolated:

  • An API key scoped to development cannot evaluate against the production deployment
  • Evaluation history is per-environment: you can query evaluations for a specific environment
  • Each environment has one active deployment per boundary (or none, if no version of that boundary has been deployed)

Typical Setup

Section titled “Typical Setup”
Project: payment-processing
├── development   → boundary version 3 (latest, under test)
├── staging       → boundary version 2 (release candidate)
└── production    → boundary version 1 (verified stable)

Developers test against development with the latest boundary version. The staging environment runs the release candidate. Production uses the last verified stable version.

Promotion Flow

Section titled “Promotion Flow”

Promoting a boundary through environments:

  1. Deploy boundary version 3 to development
  2. Test with sample workloads
  3. Deploy version 3 to staging (the previous deployment becomes SUPERSEDED)
  4. Run certification models against staging
  5. Deploy version 3 to production

Promotion requires an explicit boundary version ID: you specify exactly which compiled version to deploy, preventing TOCTOU races.

API Keys and Environment Scoping

Section titled “API Keys and Environment Scoping”

API keys are scoped to a specific environment. When you create an API key for the production environment, that key can only be used to evaluate against the production deployment.

client = VBOSClient(api_key="PRODUCTION_API_KEY")


result = client.verify(
    workload={"transaction_amount": 15000},
    project="payment-processing",
    boundary_ref="payment-authorization",
)

The API key determines which environment’s deployment is used: you do not specify the environment in the verify request.

Next Steps

Section titled “Next Steps”