What is Bluebricks?

Understand how packages, collections, and environments work together to turn IaC into reusable, governed, and repeatable deployments.

Bluebricks is a platform for delivering infrastructure in a consistent, governed way across teams and cloud environments.

As organizations grow, infrastructure becomes harder to manage. Different teams deploy using different tools and patterns. Changes require manual coordination. Approvals often happen informally. Standards drift over time. This increases operational risk and slows down delivery.

Bluebricks addresses this by standardizing how infrastructure is defined, approved, and executed, without replacing the underlying Infrastructure as Code (IaC) tools your teams already use.

It sits above tools like Terraform, OpenTofu, Helm, CloudFormation, and Bicep, providing:

• Reusable infrastructure building blocks

• Controlled deployment workflows

• Policy enforcement and approvals

• Auditability for every change

• Clear separation between what is deployed, where it runs, and how it is executed

The result is infrastructure that can scale across teams without losing consistency or control.

Bluebricks organizes infrastructure management around three core concepts: Packages define what you deploy, collections define where it goes, and environments define how it runs. Everything in the platform builds on these three building blocks.

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. This makes infrastructure composable and shareable across teams.

There are two types of Packages:

• Artifact -- A single IaC component (a Terraform module, a Helm chart, a Bicep template, etc.) with defined inputs, outputs, and metadata. Artifacts are not deployed on their own -- they 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.

For example, you might have a VPC Artifact and a subnet Artifact. A network Blueprint composes the two, passes the VPC ID into the subnet, and exposes only region and cidr_block as inputs. The deployer never touches the underlying wiring.

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 -- a logical unit that 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. This keeps Packages reusable while adapting them to each target.

• 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 trigger 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 it -- 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.

This gives you:

• Consistency -- every change follows the same evaluation and execution workflow.

• Traceability -- every Run is recorded with its plan, inputs, and outputs.

• Repeatability -- Environments can be re-run at any time for iterative updates.

• Safety -- Collection Policies, approval flows, and cost checks run automatically before changes are applied.

Learn more about Environments