Customers Asked for Bicep. We Listened.

One thing that was important for us right from the beginning: we're not going to force anyone to abandon their existing infrastructure tools.

We decided early on to build Bluebricks as a truly tool-agnostic platform—not just as a feature, but as a core principle.

Here's why:

Teams spend months building infrastructure in Terraform, Helm, or CloudFormation. That code works. It's tested. It's in production. Bicep Was Our Obvious Next Step

Over the past few months, our customers kept bringing up Bicep support as a crucial need.

These weren't one-off requests. Platform teams running production Azure infrastructure needed to know if Bluebricks would work with their Bicep templates, or if they'd need to migrate everything to Terraform first.

The pattern was clear: serious Azure shops chose Bicep deliberately, and they needed orchestration that respected that choice.

What Makes Bicep Different

Our customers choose Bicep for specific reasons:

It's Microsoft's native IaC language for Azure. Day-one support for new Azure services. Native resource validation. Built into the Azure CLI—no separate tools, no licensing.

It works better for Azure-heavy infrastructure. It understands Azure resource relationships natively. No waiting for provider updates. No working around Azure-specific quirks through generic abstractions.

What We Built

Bicep templates now work in Bluebricks like any other tool:

• Publish Bicep templates as packages—we auto-detect parameters from your schema

• Outputs flow automatically to other resources (Terraform, Helm, whatever)

• ARM deployments tracked in unified state management

• Everything visible in one environment view

Example: Bicep template provisions Azure SQL, outputs connection string, feeds into Helm chart automatically. No manual wiring.