Creating Artifacts via CLI

Create reusable Infrastructure as Code artifacts in Bluebricks to standardize infrastructure and enable consistent deployments across environments

Overview

This guide covers publishing artifacts using the bricks CLI. Use this approach when Bluebricks cannot access your repository directly, for example with private repos without the GitHub integration, or non-GitHub version control systems.

If you've connected GitHub or are using a public repo, you can create artifacts directly in the Bluebricks app during blueprint creation. See Creating Blueprints to learn how

Supported IaC types

Bluebricks supports multiple IaC technologies:

• Terraform

• OpenTofu

• Helm

• CloudFormation

• Bicep

• Generic (container-based execution)

Don't have code that defines your resources yet? Let the cloud import agent codify them for you.

How to publish artifacts via CLI

An artifact is automatically generated through a single CLI command from the code's directory.

Prerequisites

• Installed bricks command line

1

Navigate to your code's root folder

For example:

my_s3_module/
├── main.tf              # Infrastructure definitions
├── variables.tf         # Input variables
├── outputs.tf           # Output values
└── versions.tf          # Provider versions

Your code must be self-contained and executable with its native tool, such as terraform init/plan/apply or helm install. For Terraform or OpenTofu, this means the root module you would normally navigate into and run directly.

2

Publish with the CLI

Publish it from the artifact directory:

bricks blueprint publish

This command generates a slim metadata file (bricks.json) and publishes it into the Bluebricks catalog.

3

View your artifacts

Go to the Artifacts page in Bluebricks to see your new artifact.

How to update your artifacts with CLI

Following any change to the underlying IaC you should update your artifact and re-publish it.

1

Navigate to your code's root folder

2

Change the artifacts version

Run the following command to update the semantic version

bricks blueprint bump

You can also manually open the bricks.json file of the artifact, change the version and save it.

3

Publish the new version

Publish the new version using

bricks blueprint publish

Artifact example

Every artifact is defined by a bricks.json file at its root.

This file describes:

• The artifact name

• Semantic version

• Inputs (props)

• Outputs (outs)

• The native IaC implementation (native)

Example:

{
  "name": "aws_vpc",
  "description": "Creates a VPC with public and private subnets",
  "version": "1.2.0",
  "native": {
    "type": "terraform",
    "path": "./terraform"
  }
}

A standard artifact repository:

my_s3_artifact/
├── bricks.json          # Artifact definition
├── main.tf              # Infrastructure definitions
├── variables.tf         # Input variables
├── outputs.tf           # Output values
└── versions.tf          # Provider versions
├── README.md            # Documentation
└── examples/            # Usage examples
    └── basic/
        ├── main.tf

Publishing options

The bricks blueprint publish command accepts publish-specific flags:

Flag	Description
--src <path>	Publish from a specific directory instead of the current working directory
--state	Include a .tfstate file in the published artifact for migration purposes
--resolve-modules	Resolve and include external Terraform module references (default: true)

Examples:

# Publish from a different directory
bricks blueprint publish --src ./my_artifact

# Include state file for migration
bricks blueprint publish --state

# Disable external module resolution
bricks blueprint publish --resolve-modules=false

Global CLI flags such as --api-key and --non-interactive are also available on this command. See the CLI Reference for the full list, and CLI Authentication for details on API key usage.

Publishing flow

When you run bricks blueprint publish, the CLI performs these steps:

1

Validation

The CLI validates your bricks.json configuration and checks that all required fields are present.

2

Source preparation

The artifact source code is packaged into a zip archive. External Terraform module references are resolved unless --resolve-modules=false is set.

3

Upload

The packaged artifact and bricks.json are uploaded to the Bluebricks platform as a single multipart request.

4

Registration

The artifact is registered in your organization's catalog with the version specified in bricks.json.

5

Confirmation

The CLI returns a success confirmation with the published artifact details.

Authentication for CI/CD

For automated pipelines, authenticate with an API key instead of interactive login:

# Environment variable (recommended)
export BRICKS_API_KEY="bbx_your_api_key_here"
bricks blueprint publish

# CLI flag
bricks blueprint publish --api-key "bbx_your_api_key_here"

For full details on API key creation and authentication methods, see CLI Authentication.

For GitHub Actions workflows, use the Bricks Action instead of running CLI commands directly.