Module 9: Custom Templates

"Once you can deploy an app, you can package it so anyone deploys it too. Custom templates turn your project into a one-command starting point."

Level: Beginner · Time: ~2 days · Prerequisites: Modules 5–8

Learning Objectives

By the end of this module, you will be able to:

• Explain what an azd template contains
• Turn your project into a reusable template
• Share a template with others
• Understand template structure and conventions

1. What a Template Is

An azd template is simply a repository laid out so azd init and azd up work out of the box. It contains your app code, the infra/ Bicep, the azure.yaml, and usually a .devcontainer and a helpful README. Anyone who clones it can deploy the whole thing in minutes.

Because everything needed to run lives in the repo, there's no hidden setup stranded on the original author's laptop. The README explains what the app is; azd handles standing it up in the cloud.

2. The Standard Layout

Templates follow a predictable structure so azd (and people) know where things are:

my-template/
├── azure.yaml          # services + hosts
├── infra/              # Bicep infrastructure
│   ├── main.bicep
│   └── main.parameters.json
├── src/                # application code
├── .devcontainer/      # ready-made dev environment
└── README.md           # what it does + how to run

azd doesn't force this exact layout, but following it means the tooling finds azure.yaml and infra/ automatically, and newcomers instantly know where to look.

3. Making Your Own

To turn a working azd project into a shareable template: make sure it has a clean azure.yaml and infra/, add a clear README, remove anything machine-specific, and push it to a Git repo. Others then start from it with:

azd init --template your-org/your-template

Before you share it, run azd up from a fresh clone yourself — that's the truest test that a stranger can deploy it cleanly, with nothing missing. You can also register a template in the community gallery so it shows up in azd init alongside Microsoft's.

4. Parameters Keep Templates Flexible

Good templates expose choices as parameters (in main.parameters.json) rather than hard-coding them — region, app name, SKU sizes. Users set their own values without editing your Bicep.

A parameter is just a named input with an optional default. Expose region, SKU, and app name, and one template can serve a hobby project on the cheapest tier and a production app on a larger one — no code edits, only different values.

5. Why Templates Matter

Templates are how azd's ecosystem thrives: Microsoft and the community publish hundreds, so you rarely start from zero. Publishing your own lets teammates (or the world) stand up your architecture instantly — a powerful way to share best practices, since one team's well-designed setup becomes every other team's starting point.

✅ Checkpoint

1. What does an azd template contain?
2. How does someone start a project from your template?
3. Why should templates use parameters instead of hard-coded values?

Answers: 1) App code, infra/ Bicep, azure.yaml, usually a .devcontainer and README — laid out so azd up works. 2) azd init --template your-org/your-template. 3) So different users can set their own region/names/sizes without editing the Bicep, and avoid name clashes.

Further Learning

• Create azd templates
• Awesome AZD gallery

Part of "AZD for Beginners." Adapted from Microsoft's open AZD curriculum (MIT License).