Collections

A collection is a logical unit for provisioning cloud infrastructure

A Bluebricks Collection is a logical unit for provisioning and managing cloud infrastructure. A collection can be tied to a specific cloud provider account, region, or an on-premises target, and member access is controlled via RBAC so permissions remain clear and auditable. You can attach properties and secrets to a collection; those values are automatically inherited by any package deployed to that collection, keeping packages reusable while allowing them to adapt to their environment context.

Collections organize infrastructure into clear units that map to how teams actually work: for example, projects, teams, or lifecycle stages such as development, staging, and production. Each collection serves as the foundation for environments by holding shared settings, credentials, and governance rules that determine where and under which policies blueprints are executed.

For details on managing who can access a collection, see Owners and Members.

What a collection contains

A Collection is more than a label: it bundles the practical pieces Bluebricks needs to operate safely and predictably:

• Target configuration: cloud account and any contextual identifiers that determine where resources are created.

• Policy surface: the set of Collection Policies (approvals, cost limits, allowed blueprints, etc.) that govern what runs and how.

• Variables & secrets: collection-scoped inputs, secret references, and parameter defaults that environments consume.

• RBAC & access controls: who may create, edit, approve, or execute environments in the collection.

This bundle ensures that every environment targeted at a Collection follows consistent operational rules and can be audited, repeated, and governed.

The collection detail page

When you review a collection, the detail page organizes everything into five tabs: Overview, Environments, Policies, Properties, and Secrets.

Overview tab

The Overview tab is the default view. It shows general information about the collection and the team members assigned to it.

General info displays at the top of the page

• Name and color: the collection display name and color badge

• Slug: the unique identifier used in CLI commands and API calls

• Cloud account: the connected cloud provider and account

• Monthly cost: the current cost against the configured cost limit (visible when the Cost Limit policy is enabled or the current cost is above zero)

Members lists all users assigned to the collection

Each row shows the user and their role (Owner or Member). From this table you can:

• Add new members to the collection

• Change a member's role

• Remove a member

For details on roles and access control, see Owners and Members.

Environments tab

The Environments tab lists all live environments in the collection. Each row links to the environment detail page where you can review runs, manage state, and configure drift detection.

Click Run to create a new environment by deploying a blueprint to this collection.

The Run button is disabled if the collection has no connected cloud account or is locked.

Policies tab

The Policies tab lets you enable and configure rules that govern how environments run in this collection. Four built-in policies are available:

• Owner Approval: require an owner to approve each run before it executes

• Cost Limit: set a maximum cost threshold for infrastructure changes

• Allowed Blueprints: restrict which blueprints (and versions) can deploy to the collection

• Allow Pre-Release Versions: permit pre-release blueprint versions

For details on how each policy works and how enforcement is applied, see Policies.

Properties tab

The Properties tab lets you create, edit, and delete key-value properties scoped to the collection. Properties automatically flow into every blueprint deployed here, supplying values like regions, naming conventions, or account-specific defaults. Properties marked as enforced cannot be overridden by environments.

For details on how properties are injected and how to use dynamic values, see Properties.

Secrets tab

The Secrets tab lets you create and delete encrypted secrets scoped to the collection. Secrets store sensitive values like API keys, credentials, or tokens that are injected into blueprints at runtime. Secret values are write-once; they cannot be viewed or edited after creation.

The Add secret button is disabled if the collection is locked or has no encryption key configured.

For details on how secrets are referenced in blueprints, see Secrets.

Best practices

• Name and scope collections clearly (e.g., dev-us-east-1, staging, prod-eu) so teams and automation can target them unambiguously.

• Segment sensitive workloads into dedicated collections or accounts to enforce strict security boundaries.

• Use collection policies to protect production and apply cost controls in shared collections.

• Keep collection variables minimal and explicit: treat them as the contract for environments.