# Azure ResourceModules: CARML, AVM, and the curated Bicep modules

> The Azure ResourceModules repository was the Common Azure Resource Modules Library, a collection of mature Bicep modules with a continuous integration platform for validating and publishing them. It has since been rebranded as the Bicep form of Azure Verified Modules, and the repository is now largely a transition notice that tells you where each module lives and what still receives updates.

**Azure/ResourceModules** — This repository includes a CI platform for and collection of mature and curated Bicep modules. The platform supports both ARM and Bicep and can be leveraged using GitHub actions as well as Azure DevOps pipelines.

- Repository: https://github.com/Azure/ResourceModules
- Website: https://aka.ms/carml
- Stars: 738 · Forks: 435
- Language: PowerShell
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/azure-resourcemodules

## The repository is now a transition notice

The first thing in the README is a heading in the shape of a warning, and it says that CARML evolved to and has been rebranded as the Bicep version of Azure Verified Modules, with AVM described as a straight-line successor and the next evolutionary step. It adds that a lot of CARML's principles and architecture decisions have formed the basis for AVM.

So this repository, which was one of the most useful collections of Bicep modules for Azure, is no longer the place where that work happens. The README is explicit that while this means some minor changes in things such as parameter names or the standard interfaces, for example diagnostic settings, you can still use the same modules you are used to, as they have been transitioned to AVM as resource or pattern modules.

Two pointers close the loop. The full list of all AVM modules is in the AVM module indexes, and each module is published in the Public Bicep Registry, with the source code in the underlying repository, which the README links to under the name BRM.

And there is a fallback for anyone who still needs the older version. A notice with additional details has been placed in each module, and if you need the CARML version of a module for any reason, you can find it in the CARML repository by following the links in the module's README file.

The result is a repository that is still worth reading, because it is where the history, the catalogue, and the conventions live, even though the code has moved.

## What the repository actually contains

Below the transition notice, the README describes the library as it was, and that description is still the accurate summary of the code in the tree.

It includes a library of mature and curated Bicep modules, and a continuous integration environment that is used for the modules' validation and versioned publishing. The CI environment supports both ARM and Bicep, and it can be leveraged using GitHub actions as well as Azure DevOps pipelines.

The top level of the repository shows the structure that supports that. There is a modules directory, which is the catalogue itself, and a constructs directory for the higher level building blocks, a utilities directory for the shared helpers, a docs directory, an Azure DevOps directory, a GitHub directory, a bicepconfig.json, a settings.yml, and a set of governance files: a code of conduct, a contributing guide, a security policy, and a support policy.

Two of those files are worth knowing about without reading them. The bicepconfig.json is the Bicep configuration, which is where the registry configuration and the module aliases live, and it is the file that makes the curated module experience work rather than just a folder of templates. The settings.yml is the shared configuration the CI environment reads, and it is the place where the standards for a module live, which matters because the point of a curated library is that every module in it behaves the same way.

The .lycheeignore file is a small detail that says something about the maturity of the setup. Lychee is a link checker, and ignoring links is what you do when your documentation contains links to services that need authentication or that are known to be temporarily unavailable.

## The module catalogue, and what a standard interface means

The catalogue is a table with three columns, the provider namespace, the resource type, and the name, and it is organised by provider, which is the same taxonomy Azure itself uses.

The Microsoft.AAD namespace holds domain services, the Azure Active Directory Domain Services. Microsoft.AnalysisServices holds servers. Microsoft.ApiManagement holds services. Microsoft.App holds container apps, then container app jobs, then managed environments, all in the same namespace with the provider repeated only once. Microsoft.AppConfiguration holds configuration stores.

And then Microsoft.Authorization, which is the densest group in the visible part of the table, with locks, policy assignments, policy definitions, policy exemptions, policy set definitions, and role assignments. Every one of those is listed as applying to all scopes.

That last group is the interesting one, because it is a set of modules that have nothing to do with each other except that they are all governance resources. They live together because they are all the things you attach to a resource or a subscription to control who can do what. The alternative would have been one module per resource type, and the choice to group them by the fact that they share an interface rather than by the resource they govern is a design decision you can read straight out of the table.

The standard interface idea is what makes the library usable at scale. The README names diagnostic settings as an example of a standard interface, and the point is that a module for a database and a module for a virtual network both emit their diagnostic settings in the same shape, so the code that collects logs and metrics does not have to know which module produced them. The transition to AVM changed some of the details, and the parameter names, but the idea carried over.

## The CI platform, and the two pipelines it runs in

The continuous integration environment is the part of this repository that is genuinely unusual, and it is the reason to look at it even if you do not use the modules.

The environment is what validates a module and publishes it in a versioned way, and it supports both ARM and Bicep, which is a bigger commitment than it sounds, because the two are different deployment languages with different toolchains and different failure modes. A validator that handles both is checking a module twice.

The second unusual property is that the platform itself is consumed through two different CI systems, GitHub actions and Azure DevOps pipelines. The repository carries a directory for each, and the README describes the environment as something that can be used with both. That is unusual because most infrastructure is tied to one, and supporting both means the environment is portable rather than a set of scripts that happen to run on one service.

The inner-sourcing arrangement is what sits underneath. The project is a Microsoft repository, and the CI environment is the internal pipeline used to validate modules before they are published. The README notes that in the upcoming period, the AVM team will work on ensuring full compatibility of the CARML inner-sourcing solution, the CI environment, with AVM. So the transition is not only about moving code, it is about keeping the validation and publishing machinery working across the two lineages.

For an open source user, the practical implication is that the module you consume is not just a template. It has been through a validation pipeline that checks it against a shared standard, which is the difference between a curated module and a template you found in a blog post.

## Where to file issues, and what is still maintained

The README is unambiguous about the support model, and reading it will save you from filing in the wrong place.

Going forward, only the AVM version of the modules will receive updates and new features. The request is not to file issues in CARML or to work on improving a module in CARML, because further contributions to those modules will not be integrated into the CARML repository. To open an AVM module issue, use the module issue template in the BRM repository. And if you accidentally raise an issue in the wrong place, the team will transfer it to its correct home, the AVM Bicep repository.

There is one wrinkle, and it is stated separately. A few modules have been retired without being moved to AVM as they were. In most of those cases, the capabilities that the modules originally provided have been implemented differently in AVM, for example as part of all AVM modules.

That is the sentence to read twice, because it covers the most common failure in a migration. You will look for the module you used, find that it is not in the AVM index, and conclude that the capability is gone. It is not gone, it has been folded into the general module set.

The support surface for the repository itself is standard. There is a wiki with the introduction guidance, a disclaimer page for guidance on which version of the code to use, a contribution guide, GitHub issues with a template chooser, a support policy, and a security policy.

## Tooling, versions, and the practical advice

Two practical points from the README determine whether the modules work for you today.

The first is a note about tool versions. To ensure the modules and the environment work as expected, you are asked to use the latest version of the tools such as PowerShell and Bicep. In the case of Bicep specifically, the note says you need to manually update the Bicep CLI, and it points to a troubleshooting guide for the CI environment.

The manual update is not an oversight in the instructions, it is a fact about how the Bicep CLI is distributed. It is a standalone binary that is not managed by the same tooling as the rest of the stack, so a machine that was set up a year ago can have a CLI that is a year behind, and the failures that produces look like module bugs rather than version skew.

The second is where the reference documentation lives. For reference documentation the README points at Enterprise Scale, which is the reference architecture documentation, and for an outline of the module features there is a module overview in the wiki. The reference documentation is the more valuable of the two for most teams, because it shows what a well built Azure deployment looks like, and the modules are the pieces of it that you can lift directly.

On the version history of this repository itself, the releases are v0.11.1 from 2023-09-20, v0.11.0 from 2023-09-10, and v0.10.0 from 2023-03-24, with the last push on 2026-10-20. So the repository still receives commits while its version line stopped in 2023, which is the signature of a project whose publishing has moved elsewhere. If you are starting a new deployment today, take the AVM modules from the registry, and read this repository for the conventions and the catalogue rather than for the code.

## Conclusion

The Azure ResourceModules repository fits a team that already uses the CARML modules and needs to know where each one went, and it is the reference for the naming and standard interface conventions the curated modules share. It does not fit a team looking for a maintained source of Bicep modules, because the modules themselves have moved and the repository says so plainly. Verify first that the module you need exists in the AVM module indexes, that the AVM version of it matches the standard interface you expect for diagnostic settings and similar, and that your Bicep CLI and PowerShell are current, because the documentation explicitly asks for the latest tools and notes that the Bicep CLI has to be updated by hand.

## FAQ

### What happened to the CARML modules in the Azure ResourceModules repository?

CARML evolved to and was rebranded as the Bicep version of Azure Verified Modules, with AVM described as a straight-line successor. The modules have been transitioned to AVM as resource or pattern modules and are published in the Public Bicep Registry, with their source in the underlying repository linked as BRM.

### Does the Azure ResourceModules repository still receive updates?

Only the AVM version of the modules receives updates and new features. The README asks that issues are not filed in CARML and that modules are not improved there, because further contributions to those modules will not be integrated into the CARML repository.

### What does the Azure ResourceModules CI platform do?

It is the continuous integration environment used for the modules' validation and versioned publishing. It supports both ARM and Bicep, and it can be leveraged using GitHub actions as well as Azure DevOps pipelines, so the same environment runs on either CI system.

### What happened to CARML modules that were not moved to AVM?

A few modules have been retired without being moved to AVM as they were. In most of those cases, the capabilities they originally provided have been implemented differently in AVM, for example as part of all AVM modules, so the capability is not lost even though the module name has gone.

### What tools do I need to use the Azure ResourceModules CI environment?

The latest versions of tools such as PowerShell and Bicep, and in the case of Bicep you need to manually update the Bicep CLI, since it is a separate binary. There is a troubleshooting guide for the CI environment in the repository.

## Sources

- [Azure/ResourceModules on GitHub](https://github.com/Azure/ResourceModules)
- [License: MIT](https://github.com/Azure/ResourceModules/blob/main/LICENSE)
- [Project website](https://aka.ms/carml)
- [README](https://github.com/Azure/ResourceModules/blob/main/README.md)
- [Releases](https://github.com/Azure/ResourceModules/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/azure-resourcemodules