# What is Bluebricks? Bluebricks is an infrastructure platform that enables agents to discover, reason about, and operate your cloud infrastructure safely. It starts by building a **context layer**: a structured map of every resource, relationship, and dependency across your cloud accounts and infrastructure code. This shared context is what makes autonomous infrastructure operations possible, because agents can see the full picture before they act. ## Why this matters AI tools for code are effective because code is self-contained. Infrastructure is not. Infrastructure is fragmented across systems. Terraform manages declared resources, cloud providers reflect runtime state, and Git repositories store the source of truth. Each system operates independently, with no shared understanding of how they connect. Without that connection: * An agent that only sees your code cannot determine what is actually running * An agent that only sees your cloud cannot determine what is managed or intended * Changes are difficult to reason about, validate, and execute safely Giving an agent access to your cloud account is not enough. It needs a structured, continuously updated model of how your infrastructure fits together. That is the context layer. ## The context layer When you connect your cloud accounts and infrastructure code, Bluebricks builds a **context layer**: a structured map of your entire infrastructure environment. The context layer captures: * **Every cloud resource** across connected AWS, Azure, and GCP accounts, whether managed by code or not * **Relationships between resources**: networking dependencies, IAM bindings, service connections, cross-account references * **Code-to-cloud mapping**: which resources are governed by infrastructure code, which modules manage them, and where the code lives * **Drift detection**: differences between what your code declares and what is actually running The context layer updates continuously. When you connect a new cloud account, Bluebricks runs discovery: a read-only scan that indexes every resource in that provider. Discovery refreshes periodically so the context layer reflects the current state of your infrastructure, not a stale snapshot. This is the foundation that the rest of Bluebricks is built on. The [agent](https://bluebricks.co/docs/agent/agents-overview) queries the context layer to answer questions, identify risks, and execute changes. The [orchestration platform](#orchestration) uses it to resolve dependencies and generate accurate plans. ## How agents operate safely The context layer does not just give agents visibility. It constrains how they operate. Because the agent sees the full dependency graph before acting, it can predict the impact of a change before proposing it. Every change the agent makes follows the same governed workflow as manual operations: * **Plan before apply**: the agent generates a plan showing exactly what will change. Nothing executes until you approve * **All changes go through IaC**: the agent does not make direct cloud API calls. Changes are codified in pull requests or environment runs, version-controlled, and auditable * **RBAC and policies are enforced**: the agent respects your collection-level roles, permissions, and policies. If you cannot approve a deployment manually, the agent cannot do it for you * **Organization-scoped**: all queries and actions are scoped to your organization at the database level. The agent cannot access resources outside your org This is not a set of guardrails bolted onto a chat interface. The context layer and governance model are the same system, so safety is structural, not behavioral. For a detailed look at how the agent uses the context layer to discover, remediate, and deploy, see [Agent Overview](https://bluebricks.co/docs/agent/agents-overview). ## Orchestration Alongside the agent, Bluebricks provides a full orchestration platform for governed, repeatable deployments. You define reusable building blocks, target them at specific cloud accounts, and run deployment pipelines with plan/approve/apply cycles. The agent and the orchestration platform share the same context layer, governance rules, and approval workflows. Teams can use either interface, or both, depending on what fits their workflow. 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](https://bluebricks.co/docs/orchestration/packages) 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.
More about packages 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 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. Read more about [packages](https://bluebricks.co/docs/orchestration/packages).
### Collections A [collection](https://bluebricks.co/docs/orchestration/collections) is the deployment target. It groups a cloud account, access rules, shared configuration, and governance policies into one place.
More about collections 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`. Read more about [collections](https://bluebricks.co/docs/orchestration/collections).
### Environments An [environment](https://bluebricks.co/docs/orchestration/environments) is the workflow that deploys a package into a collection. It is where *what* (the package) meets *where* (the collection) and produces real infrastructure.
More about environments When you deploy an environment, Bluebricks evaluates the package and all its dependencies 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. Read more about [environments](https://bluebricks.co/docs/orchestration/environments).