Creating Blueprints

Combine multiple packages into a reusable, deployable infrastructure template

Overview

Blueprints define reusable infrastructure templates made of one or more packages. They let you standardize cloud resources, reduce duplication, and share consistent infrastructure patterns across environments.

This guide walks you through creating a new blueprint in the Bluebricks App and understanding it's underlying json interface.

Creating a Blueprint

1. Define Blueprint Metadata

At the top of the wizard, enter the core details:

• Name – Unique within your organization

• Version – Must follow semantic versioning (e.g., 1.0.0)

• Description – Optional, for internal context

• Tags – Optional, for search and organization

1. Add Packages

Blueprints are comprised of other packages which can be Artifacts or other Blueprints.

To add a package:

1. Click + Add Package

2. Choose from published artifacts or blueprints

3. Each added package appears as a card in the list

Every package has:

• A unique ID, auto-generated using the pattern:

[package_name]_[short_hash]

You can edit this ID manually if you need deterministic references.

1. Manage Properties and References

Each package, whether an artifact or another blueprint, defines its own properties (inputs it requires) and outputs (values it produces).

When you add a package, Bluebricks automatically imports its internal schema so you can configure or expose the parts that matter for your blueprint’s interface.

Outputs

Outputs are values produced by a package or nested blueprint, such as resource IDs or URLs. These can be used inside your blueprint (via data. references) or exposed to deployers as part of your blueprint’s interface.

Most outputs remain hidden in the UI because they’re internal—used only to connect packages together.

Properties

Properties represent configuration inputs for a package: values like region, VPC ID, or instance type. Most of these properties are hidden by default in the UI because they belong to the internal implementation of the package or a nested blueprint. You’ll only see them in the interface if you choose to expose them to the deployer.

You expose a property by setting it as either Default or Required:

Required	Must be provided by the deployer at deployment time. Shown as a read-only placeholder in the UI.	Used for parameters that always vary between environments (e.g., vpc_id, cluster_name).
Default	Predefined value that can be overridden by the deployer.	Useful for configuration values that usually stay constant but can be customized.
Value	Hard-coded value defined by the builder. Unmodifiable by the deployer.	Used for wiring internal dependencies (e.g., linking to another package’s output).
Allowed Values	Predefined values that can be selected from by the deployer

For Example

packages:
  - name: eks_auto_mode
    props:
      region: inputs.region          # exposed to deployer
      vpc_id: inputs.vpc_id          # exposed to deployer
      cluster_name: "staging-cluster" # hidden, fixed value

In the resulting slim bricks.json, only region and vpc_id appear as part of the deployer interface. The cluster_name remains in the underlying package schema, but not visible to users deploying the blueprint.

Data and Secret References

• Data: Reference outputs from other packages: Data.<package_name>.<output_name>

• Secret: Reference secrets from your secret manager: Secrets.<secret_name>

Advanced Features

• Expression Language: Use expr for dynamic values, conditionals, and more. See How to use expr in Blueprints for details.

• Immutability: Once published, blueprint versions are immutable. To change, create a new version.