Build Test Azure CLI Integration Needs Upvote Good First Issues

Azure Bicep

For all you need to know about the Bicep language, check out the 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 started with Bicep:

  1. Install 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 Azure Resource Manager (ARM) template or set of Azure resources that you want to convert to .bicep format, see the recommended workflow for migrating resources to Bicep and Decompiling an ARM Template.

Also, there's 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 by using the Bicep language service as part of the Bicep VS Code extension.

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

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 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 have a lot of freedom to modularize and re-use their code. Code re-use shouldn't require any 'copy/paste'-ing.
  5. Tooling should provide a high level of resource discoverability and validation. Develop it alongside the compiler rather than adding it 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 language doesn't replace general-purpose languages. You might 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 the extensibility model supports 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. You can use Bicep to provision any ARM resource, whether it's in private, public preview, or GA.
  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 it's easy to collaborate and make changes to resources confidently.
  4. Tooling is the cornerstone to any great experience with a programming language. The 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

The Bicep team is here to help you be successful with Bicep. Don't hesitate to reach out.

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

Community call

The Bicep team hosts 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 the 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 in touch with other users through the community-created Azure Bicep users group on LinkedIn.

Reference

Community Bicep projects

Alternatives

Because the ARM Template is now treated as an IL, other implementations of IL (ARM Template) generation are expected and encouraged. This list provides alternatives for creating ARM templates that might better fit your use case.

Telemetry

When you use the Bicep VS Code extension, VS Code collects usage data and sends it to Microsoft to help improve our products and services. Read the privacy statement to learn more. If you don't want to send usage data to Microsoft, set the telemetry.enableTelemetry setting to false. For more information, see the FAQ.

License

All files in the repository, except for the Azure Architecture SVG Icons (here and here), 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

For information on building and running the code, contributing code, contributing examples, and contributing feature requests or bug reports, see Contributing to Bicep.