Environments

Environments execute blueprints against collections and track changes

A Bluebricks Environment provides a consistent, controlled, and repeatable way to execute a blueprint against a specific collection. An environment represents the ongoing workflow responsible for provisioning, updating, and destroying all infrastructure defined by the blueprint, across every package, artifact, and dependency it contains.

Once created, an environment serves as the stable interface for managing the lifecycle of your infrastructure in that collection. It centralizes configuration, tracks every change, and ensures that updates are performed safely and predictably, regardless of how they are triggered.

How environments work

When you create an environment run, Bluebricks evaluates the blueprint and all of its child packages to produce a unified execution plan. This plan captures every expected change across all layers of infrastructure, allowing you to:

• Preview changes before applying them

• Understand the full impact of updates

• Maintain an auditable history of every modification

Each execution of an environment creates a run, which encapsulates the plan, logs, state updates, and resulting outputs. Runs are fully versioned and traceable, enabling teams to understand how infrastructure evolves over time and why each change was made.

What an environment contains

An environment bundles configuration, execution history, and lifecycle controls into a single manageable unit:

• Blueprint binding: the specific blueprint (and version) that defines the infrastructure to provision.

• Collection target: the collection that determines where resources are created and which policies, variables, and secrets apply.

• Run history: a full audit trail of every plan, apply, and destroy run, including logs, diffs, inputs, and outputs.

• Lifecycle controls: drift detection schedules, TTL rules, and archiving state that govern how the environment behaves over time.

Best practices

• Use descriptive slugs (e.g., networking_prod, data_staging) so environments are easy to identify in lists and automation.

• Review the unified plan before approving to understand the full impact of changes across all packages.

• Enable drift detection on long-lived environments to catch out-of-band changes early.

• Set a TTL on ephemeral environments (e.g., feature branches, demos) to avoid unused infrastructure accumulating cost.

• Archive environments you no longer need instead of leaving them in the active list. See Archiving Environments.