Versions
The Web App Blueprint pins OpenTofu 1.12.6, Terragrunt 1.1.6 and the azurerm provider ~> 5.7, creates its clusters on Kubernetes 1.36 and its database on MongoDB 8.0, and runs a Python 3.12 API with a React 19 front end. Every Helm chart, Python package and GitHub Action is pinned in the code, so a plan or a build means the same thing on every machine.
Where the pins live
root.hcl generates the provider pins into every unit. A module that needs the Helm or Kubernetes provider, or an aliased azurerm provider for another subscription, ships its own versions.tf that repeats the same pins:
generate "versions" {
path = "versions.tf"
if_exists = "skip"
contents = <<-EOF
terraform {
required_version = ">= 1.12.6"
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = "~> 5.7"
}
random = {
source = "hashicorp/random"
version = "~> 3.7"
}
}
}
EOF
}
scripts/check-module-versions.py enforces the rule in pre-commit and in the plan workflow: a module may carry versions.tf only when it needs one, and then its OpenTofu and azurerm constraints must equal those of root.hcl.
Tools and providers
| Component | Version | Pinned in |
|---|---|---|
| OpenTofu | 1.12.6 (constraint >= 1.12.6, < 2.0.0) | root.hcl, workflows |
| Terragrunt | 1.1.6 | root.hcl, workflows (with its SHA-256) |
| azurerm provider | ~> 5.7 | root.hcl and module versions.tf |
| random provider | ~> 3.7 | root.hcl |
| Helm provider | ~> 3.3 | Module versions.tf |
| Kubernetes provider | ~> 3.2 | Module versions.tf |
| tflint | 0.64.0 | Plan workflow, pre-commit |
| kubelogin | v0.2.20 | Plan, apply and drift workflows |
Platform versions
| Component | Version |
|---|---|
| Kubernetes on AKS | 1.36 at creation; the patch auto-upgrade channel keeps it current within the minor version |
| AKS support plan | KubernetesOfficial |
| Node operating system | Azure Linux on the system pool and on every Node Auto Provisioning node |
| Node image | The NodeImage channel, inside the weekly maintenance window |
| Cosmos DB for MongoDB vCore | MongoDB 8.0 |
| Azure Managed Redis | The service's current version; the blueprint sets the SKU, not an engine version |
The managed add-ons, the application routing add-on's NGINX, Container Insights, the Azure Policy add-on, the image cleaner and the workload identity webhook, are versioned by AKS with the cluster. How the Kubernetes version moves is on cluster version.
Helm charts
| Chart | Repository | Version | Variable |
|---|---|---|---|
external-secrets | https://charts.external-secrets.io | 2.6.0 | eso_chart_version |
cert-manager | https://charts.jetstack.io | v1.21.2 | chart_version |
argo-cd | https://argoproj.github.io/argo-helm | 9.5.22 | argocd_chart_version |
cert-manager v1.21 is the line that supports Kubernetes 1.33 to 1.36, which is why it moves with the cluster's minor version. The in-cluster objects the units create use these API versions: karpenter.azure.com/v1beta1 for AKSNodeClass, karpenter.sh/v1 for NodePool, approuting.kubernetes.azure.com/v1alpha1 for NginxIngressController, external-secrets.io/v1, cert-manager.io/v1 and argoproj.io/v1alpha1.
Application runtime
| Component | Version |
|---|---|
| Base image | python:3.12-slim |
| Flask | 3.1.3, with flask-cors 6.0.5 |
| Gunicorn | 26.2.0: four workers with two threads each, on port 8080 |
| pymongo | 4.18.2 |
| redis | 8.1.0, with redis-entraid 1.2.1 |
| azure-identity | 1.26.0 |
| React | ^19.2.7, with react-router-dom ^7.17.0 and axios ^1.17.0 |
| Vite | ^8.0.16, with TypeScript ^6.0.3 |
src/requirements.txt pins every Python package exactly. The front end's ranges resolve through the committed package-lock.json, which npm ci installs.
Continuous integration
The code repository's workflows run Python 3.12, Node.js 22, ruff 0.16.10, pytest 9.1.1 and the Trivy action v0.36.0. Every third-party action in every workflow is pinned to a full commit SHA with its version in a comment.
How versions change
A version is a line of code, so it changes through a pull request like any other value: a chart variable's default in its module, the cluster_version input in units/aks/terragrunt.hcl, a pin in root.hcl or a package in requirements.txt. The plan of the infrastructure repository shows the effect on all three stages before anything moves. The rules for upgrades across BuiltForProd products are in the versioning policy.