Templates

Templates

Overview

az prototype includes five built-in workload templates that pre-configure Azure service topologies for common application patterns. Templates define which services to deploy, how they connect, default tiers and configuration values, and a requirements description that seeds the design and build stages.

Templates are optional. If no template matches the project's design, the build stage works entirely from the design architecture produced during the az prototype design conversation.

See also: Configuration for project settings and Naming Strategies for how resources are named.

Templates

1. web-app -- Web Application

A containerized web application with SQL backend, Key Vault for secrets, and API Management as the public gateway.

Services:

Service	Type	Tier	Notes
api	container-apps	consumption	Internal ingress, system-assigned MI, health probes
gateway	api-management	consumption	System-assigned MI, caching enabled
database	sql-database	serverless	Entra-only auth, TDE, threat protection, private endpoint
secrets	key-vault	standard	RBAC mode, soft-delete, purge protection, private endpoint
network	virtual-network	--	Subnets: apps, private-endpoints, apim
monitoring	log-analytics	--	30-day retention

2. serverless-api -- Serverless API

A serverless REST API using Azure Functions with SQL Database backend, optimized for low-cost dev/test with auto-pause.

Services:

Service	Type	Tier	Notes
api	functions	consumption	.NET isolated runtime, VNET-integrated, HTTPS-only, TLS 1.2
gateway	api-management	consumption	System-assigned MI, caching enabled
database	sql-database	serverless	Entra-only auth, TDE, 60-min auto-pause, private endpoint
secrets	key-vault	standard	RBAC mode, soft-delete, purge protection, private endpoint
monitoring	log-analytics	--	30-day retention
network	virtual-network	--	Subnets: functions, private-endpoints, apim

3. microservices -- Microservices

A microservices architecture with multiple Container Apps communicating via Azure Service Bus, fronted by API Management. Uses user-assigned managed identity shared across services.

Services:

Service	Type	Tier	Notes
api-gateway	api-management	consumption	System-assigned MI, caching
frontend-api	container-apps	consumption	Internal ingress, user-assigned MI, min 1 replica
order-service	container-apps	consumption	Internal ingress, user-assigned MI, scale to zero
notification-service	container-apps	consumption	Internal ingress, user-assigned MI, scale to zero
messaging	service-bus	standard	User-assigned MI, private endpoint, queues: orders, notifications
shared-identity	managed-identity	--	User-assigned, shared across all services
secrets	key-vault	standard	RBAC mode, soft-delete, purge protection, private endpoint
registry	container-registry	basic	Admin disabled, user-assigned MI
network	virtual-network	--	Subnets: apps, private-endpoints, apim
monitoring	log-analytics	--	30-day retention

4. ai-app -- AI Application

An AI-powered application with Azure OpenAI for inference, Container Apps for the API layer, and Cosmos DB for conversation history.

Services:

Service	Type	Tier	Notes
api	container-apps	consumption	Internal ingress, system-assigned MI, min 1 replica
ai-engine	cognitive-services	standard	OpenAI kind, GPT-4o deployment, private endpoint
conversation-store	cosmos-db	serverless	NoSQL API, Entra RBAC, session consistency, 30-day TTL
gateway	api-management	consumption	System-assigned MI, caching, rate limiting
secrets	key-vault	standard	RBAC mode, soft-delete, purge protection, private endpoint
network	virtual-network	--	Subnets: apps, private-endpoints, apim
monitoring	log-analytics	--	30-day retention

5. data-pipeline -- Data Pipeline

An event-driven data pipeline using Azure Functions for processing, Cosmos DB for storage, and Event Grid for orchestration.

Services:

Service	Type	Tier	Notes
processor	functions	consumption	Python runtime, VNET-integrated, HTTPS-only, TLS 1.2
datastore	cosmos-db	serverless	NoSQL API, Entra RBAC, session consistency, autoscale
ingest	storage	standard-lrs	Blob versioning, shared key disabled, public access disabled
events	event-grid	--	System-assigned MI, custom topic type
secrets	key-vault	standard	RBAC mode, soft-delete, purge protection, private endpoint
network	virtual-network	--	Subnets: functions, private-endpoints
monitoring	log-analytics	--	30-day retention

Template Structure

Each template is a YAML file (*.template.yaml) in the azext_prototype/templates/workloads/ directory. Users can also add custom templates to .prototype/templates/ in their project directory.

A template file contains four sections:

metadata:
  name: web-app                          # Unique template identifier
  display_name: "Web Application"        # Human-readable name
  description: >                         # Multi-line description
    A containerised web app with SQL backend...
  category: web-app                      # Category for grouping
  tags: [container-apps, sql, key-vault] # Searchable tags

services:                                # List of Azure services
  - name: api                            # Service identifier
    type: container-apps                 # Azure resource type
    tier: consumption                    # Pricing tier
    config:                              # Service-specific configuration
      ingress: internal
      identity: system-assigned
      min_replicas: 0
      health_probes: true

iac_defaults:                            # Default IaC configuration
  resource_group_name: "rg-{project}-{env}"
  tags:
    managed_by: az-prototype
    template: web-app

requirements: |                          # Requirements text that seeds design/build
  Build a containerised web application with:
  - A REST API running on Azure Container Apps...

The services list defines the Azure service topology. Each service entry specifies a name (used as a component identifier), type (the Azure resource type), tier (pricing/performance tier), and config (service-specific settings like ingress mode, identity type, and security options). Configuration values reference governance policy IDs (e.g., MI-001, NET-001) to indicate compliance.

Matching Logic

During the build stage, templates are automatically matched against the design architecture produced by the az prototype design conversation. The matching works as follows:

1. The architecture text from the design is loaded and lowercased.
2. Each template's service types (e.g., container-apps, sql-database, key-vault) are checked against the architecture text.
3. A match score is computed as the fraction of a template's service types that appear in the architecture: score = matches / total_service_types.
4. Templates with a score at or above 30% (0.30) are considered matches.
5. Matched templates are sorted by score (highest first) and passed to the build session.

This means a template with 6 services needs at least 2 of those service types mentioned in the architecture to qualify as a match.

When templates match, they provide the build agents with pre-configured service topologies, tiers, and configuration values. This ensures generated infrastructure code follows established patterns and governance policies. When no templates match, the build works entirely from the freeform design architecture.

The templates_used field in the build state records which templates were applied during generation.

Using Templates

At Init Time

Specify a template when creating a project:

az prototype init --name my-project --template web-app

This seeds the project with the template's requirements and service topology, giving the design stage a starting point.

Available Templates

The five built-in templates are:

Template	Use Case
web-app	Containerized web app with SQL, Key Vault, APIM
serverless-api	Serverless Functions API with SQL, auto-pause
microservices	Multi-service Container Apps with Service Bus
ai-app	AI-powered app with Azure OpenAI and Cosmos DB
data-pipeline	Event-driven pipeline with Functions, Cosmos DB, Event Grid

Custom Templates

Place custom *.template.yaml files in .prototype/templates/ within your project directory. The template registry loads both built-in and custom templates, with the same YAML schema. Custom templates participate in the same matching logic during the build stage.

Template Content Summary

All templates share common patterns:

• Key Vault is included in every template with RBAC authorization, soft-delete, purge protection, private endpoint, and diagnostics.
• Virtual Network with purpose-specific subnets (apps, private-endpoints, and optionally apim or functions).
• Log Analytics workspace with 30-day retention for monitoring.
• Managed Identity (system-assigned or user-assigned depending on the pattern) for service-to-service authentication.
• Private Endpoints for all data services (SQL, Cosmos DB, Storage, Key Vault).
• Governance policy compliance -- each service config references specific policy IDs (e.g., SQL-001 for Entra-only auth, NET-001 for private endpoints, MI-001 for managed identity).