From Code to Blueprint

Turn existing Infrastructure as Code into a reusable Bluebricks blueprint you can deploy, version, and share across teams

Bluebricks lets you take Infrastructure as Code (IaC), such as Terraform, OpenTofu, Helm, CloudFormation, or Bicep, and publish it as a blueprint: a versioned, reusable package that anyone on your team can deploy. You deploy blueprints into collections, which represent your target cloud accounts and their configuration.

This guide walks you through publishing a blueprint. You can do this two ways:

• CLI: publish a blueprint from your terminal, then create an environment separately to deploy it. Works with any Git host or local directory.

• Bluebricks app: create a blueprint and an environment in one step, with automatic runs on every push. Works with GitHub repositories or any public Git URL.

Prerequisites

• The Bricks CLI installed and authenticated (bricks login)

• A collection with at least one connected cloud account

• Infrastructure as Code in a Git repository or local directory

How to publish a blueprint from the CLI

The fastest way to turn code into a blueprint is to publish directly from your terminal. This works with any Git host (GitHub, GitLab, Azure DevOps) or a local directory.

Single module

If you have a Terraform or OpenTofu module with main.tf, variables.tf, and outputs.tf, you can publish it as a blueprint in two steps:

cd path/to/your/terraform-module
bricks blueprint publish

If no bricks.yaml or bricks.json exists in the directory, the CLI auto-detects your IaC type, generates a bricks.json with the correct metadata, packages your code, and uploads the blueprint to Bluebricks. If a config file already exists, the CLI uses it as-is. Your blueprint is now available in your organization and ready to deploy (see Deploy after publishing below).

The CLI classifies all .tf files as OpenTofu. If you are using Terraform, the behavior is the same, but the IaC type in the blueprint metadata will show as opentofu.

If both bricks.yaml and bricks.json exist in the same directory, the CLI uses bricks.yaml and ignores bricks.json.

If your code lives in a subdirectory rather than the repository root, use the --src flag:

bricks blueprint publish --src ./infra/compute

Multiple packages

If your infrastructure needs more than one module (for example, a VPC and a compute layer), you can compose multiple packages into a single blueprint using bricks blueprint init, add, and publish. For the full walkthrough, including wiring inputs and data references between packages, see Creating Blueprints.

Deploy after publishing

Once published, deploy the blueprint by creating an environment:

Bluebricks app

Go to Environments > Create environment > From blueprint, then select your blueprint.

CLI

For the full walkthrough, see Creating Environments.

How to update a blueprint

When you change your IaC code and want to publish a new version, bump the version and republish.

Bump the version

bricks blueprint bump --minor

This increments the version in your bricks.json (for example, from 1.0.0 to 1.1.0). You can also use --major or --patch depending on the scope of the change. If you omit the flag, the CLI defaults to a minor bump.

Update nested packages

If your blueprint composes other packages and you want to pull in their latest published versions:

bricks blueprint update --all

To update a specific package:

bricks blueprint update terraform_aws_vpc

Republish

After bumping and updating, publish the new version:

bricks blueprint publish

Environments pinned to the latest version of this blueprint will pick up the new version on their next run. Environments pinned to a specific version are not affected until you update their configuration.

How to publish from the Bluebricks app

You can also create a blueprint through the From code flow in the Bluebricks app. This connects your repository, creates the blueprint and environment, and auto-triggers runs on every push. Go to Environments > Create environment > From code to get started.

For the full walkthrough, see Creating Environments. For auto-trigger behavior on push and PR, see GitOps Environments.

Structuring your repository

Bluebricks is flexible about repository layout, whether your code is at the root, in a subdirectory, or spread across a mono-repo with multiple blueprints. For recommended patterns and folder structures, see Git Repository Folder Structure.

What's next?

Creating environments Deploy your blueprint into a collection

GitOps Environments Set up automatic plan and apply on every push

Day 2 Operations Scale, update, and manage deployed infrastructure

Packages Create reusable building blocks used to deploy infrastructure

Composition Patterns Wire multiple packages together

Inputs and Outputs Expose the right configuration to deployers