Build Test Azure CLI Integration Needs Upvote Good First Issues

Azure Bicep

For all you need to know about the Bicep language, check out our Bicep documentation.

What is Bicep?

Bicep is an infrastructure-as-code (IaC) programming language that uses declarative syntax to deploy Azure resources. In a Bicep file, you define the infrastructure you want to deploy to Azure and then use that file throughout the development lifecycle to repeatedly deploy that infrastructure. Your resources are deployed in a consistent manner.

Learn more about the language and benefits of using Bicep in the What is Bicep documentation.

Get started with Bicep

To get going with Bicep:

  1. Start by installing the tooling.
  2. Complete the Fundamentals of Bicep Learning Path
  3. See the full list of Learn modules for Bicep

Tip: If you're new to Bicep, start by installing the Bicep VS Code extension and deploying a simple resource (like a storage account) to get comfortable with the end-to-end workflow before moving to larger templates.

If you have an existing ARM Template or set of Azure resources that you would like to convert to .bicep format, see the recommended workflow for migrating resources to Bicep and Decompiling an ARM Template.

Also, there is a rich library of Bicep modules in Azure Verified Modules, and examples in the azure-quickstart-templates repo to help you get started. You can also use the Bicep Playground to try out Bicep in your browser.

If you're looking for production-ready and tested Bicep templates, you can find them in the bicep-registry-modules repo. Learn more about these templates on the Azure Verified Modules website: https://aka.ms/avm.

How does Bicep work?

First, author your Bicep code using the Bicep language service as part of the Bicep VS Code extension

Both Az CLI (2.20.0+) and the PowerShell Az module (v5.6.0+) have Bicep support built-in. This means you can use the standard deployment commands with your *.bicep files and the tooling will transpile the code and send it to ARM on your behalf. For example, to deploy main.bicep to a resource group my-rg, we can use the CLI command we are already used to:

az deployment group create -f ./main.bicep -g my-rg

Goals

  1. Build the best possible language for describing, validating, and deploying infrastructure to Azure.
  2. The language should provide a transparent abstraction for the underlying platform. There must be no "onboarding step" to enable Bicep support for a new resource type and/or api version.
  3. Code should be easy to understand at a glance and straightforward to learn, regardless of your experience with other programming languages.
  4. Users should be given a lot of freedom to modularize and re-use their code. Code re-use should not require any 'copy/paste'-ing.
  5. Tooling should provide a high level of resource discoverability and validation, and should be developed alongside the compiler rather than added at the end.
  6. Users should have a high level of confidence that their code is 'syntactically valid' before deploying.

Non-goals

  1. Build a general purpose language to meet any need. This will not replace general purpose languages and you may still need to do pre or post-Bicep execution tasks in a script or high-level programming language.
  2. Provide a first-class provider model for non-Azure related tasks. While we have introduced an extensibility model with current support for Microsoft Graph, official extension points are intended to be focused on Azure infra or application deployment related tasks.

FAQ

What unique benefits do you get with Bicep?

  1. Day 0 resource provider support. Any Azure resource — whether in private or public preview or GA — can be provisioned using Bicep.
  2. Much simpler syntax compared to equivalent ARM Template JSON
  3. No state or state files to manage. All state is stored in Azure, so makes it easy to collaborate and make changes to resources confidently.
  4. Tooling is the cornerstone to any great experience with a programming language. Our VS Code extension for Bicep makes it extremely easy to author and get started with advanced type validation based on all Azure resource type API definitions.
  5. Easily break apart your code with native modules
  6. Supported by Microsoft support and 100% free to use.

See more frequently asked questions on Microsoft Learn

Get Help, Report an issue

We are here to help you be successful with Bicep, please do not hesitate to reach out to us.

You can see the state of the issues in our GitHub Project.

Community call

The Bicep team is hosting an open community call for users of Bicep - go here to get invited, and follow the labeled issues for updates.

You can find recordings of our community calls on the Azure Deployments & Governance YouTube Channel.

Social media

You can also find us on social media on the following platforms:

You can also get into touch with others users on the community-created Azure Bicep users group on LinkedIn.

Reference

Community Bicep projects

Alternatives

Because we are now treating the ARM Template as an IL, we expect and encourage other implementations of IL (ARM Template) generation. We'll keep a running list of alternatives for creating ARM templates that may better fit your use case.

Telemetry

When using the Bicep VS Code extension, VS Code collects usage data and sends it to Microsoft to help improve our products and services. Read our privacy statement to learn more. If you don’t wish to send usage data to Microsoft, you can set the telemetry.enableTelemetry setting to false. Learn more in our FAQ.

License

All files except for the Azure Architecture SVG Icons (here and here) in the repository are subject to the MIT license.

The Azure Architecture SVG Icons (here and here) used in the Bicep VS Code extension are subject to the Terms of Use.

Contributing

See Contributing to Bicep for information on building/running the code, contributing code, contributing examples and contributing feature requests or bug reports.