Orchestration Overview

Manage infrastructure through the Bluebricks platform UI and CLI with governed deployment pipelines.

Bluebricks orchestration gives teams direct control over infrastructure workflows. You define reusable building blocks, target them at specific cloud accounts, and run governed deployment pipelines with plan/approve/apply cycles.

Looking for the conversational interface? The Bluebricks agent can answer questions about your infrastructure, open PRs, and manage resources through natural conversation. See Agent Overview.

The orchestration platform and the agent share the same context layer, governance rules, and approval workflows. Teams can use either interface, or both, depending on what fits their workflow.

How orchestration works

Bluebricks organizes orchestration around three core concepts: packages define what you deploy, collections define where it goes, and environments define how it runs.

Packages

A package is a reusable unit of Infrastructure as Code (IaC). Instead of managing raw Terraform modules, Helm charts, or CloudFormation templates directly, you wrap them into packages that expose clear inputs, outputs, and metadata.

There are two types of packages:

• Artifact: a single IaC component (a Terraform module, a Helm chart, a Bicep template) with defined inputs, outputs, and metadata. Artifacts are building blocks you compose into blueprints

• Blueprint: a deployable template made of one or more packages. A blueprint wires artifacts together, sets defaults and constants, and exposes only the inputs the deployer needs to provide

Blueprints support Terraform/OpenTofu, Helm, CloudFormation, Bicep, and Generic artifact types, so you can mix IaC tools within a single blueprint.

Learn more about packages

Collections

A collection is the deployment target. It groups a cloud account, access rules, shared configuration, and governance policies into one place.

Every collection can include:

• Cloud account: the AWS account, GCP project, Azure subscription, or on-premises target where resources are created

• Properties and secrets: collection-scoped values (like region, project_id, or database credentials) that are automatically inherited by every package deployed to the collection

• RBAC: member and owner roles that control who can create, approve, or execute environments in the collection

• Policies: guardrails like Owner Approval, Cost Limits, and Allowed Blueprints that govern what runs and under which conditions

Collections map to how your organization already works. For example, dev-us-east-1, staging, and prod-eu-west-1.

Learn more about collections

Environments

An environment is the workflow that deploys a blueprint into a collection. It is where what (the blueprint) meets where (the collection) and produces real infrastructure.

When you deploy an environment, Bluebricks evaluates the blueprint and all its child packages to produce a unified plan of changes. You can preview the plan, approve it, and apply or destroy the resources when they are no longer needed.

Each execution creates a run. A run captures the plan, logs, state updates, and outputs in a single auditable record. Runs are fully versioned, so you can trace exactly how your infrastructure evolved and why.

Learn more about environments

What else is in this section

• Orchestration Quick Start: Create your first collection, blueprint, and environment end to end

• Runs: Monitor execution, manage state, promote environments, and handle parallel workflows

• Cloud Graph: Visualize infrastructure across all collections, discover unmanaged resources, and codify them into blueprints

• Workflows: Git repository structure, Bricks Action CI/CD, and webhook integrations