What you receive

You receive a working web application, front end and back end, deployed into your dev, staging and prod subscriptions on top of the Azure Enterprise Baseline, together with the three Git repositories that define it, customized for your organization, and the documentation to run and change it. After handover your engineers own all of it.

How delivery works

The blueprint is sold with the Baseline in Full Deployment with Blueprints, or on its own as a Blueprint Deployment for customers who already run the Azure Enterprise Baseline. In both cases the BuiltForProd team deploys it. See blueprints for how the blueprints fit together and purchasing and licensing for the terms.

The repositories

Repository	You receive
acme-azure-blueprint-webapp-infra	Thirteen OpenTofu modules, thirteen Terragrunt units, one stack template, a stack file per stage, four guard scripts, the Front Door Private Link approval script, and the plan, apply and drift-detection workflows
acme-azure-blueprint-webapp-gitops	The blueprint-app Helm chart with its nine templates, base values, hand-maintained values per stage, and the image file per stage that the deploy pull requests write
acme-azure-blueprint-webapp-code	The Flask API and its tests, the React app, the Dockerfile, five GitHub Actions workflows and the shared action that opens deploy pull requests against the GitOps repository

acme in the names is your namespace. Your domain, your Microsoft Entra tenant, your GitHub organization and the subscriptions of the Baseline are set in the code before deployment. Every value a deployment must set carries a TODO: marker, and every switch you may change later carries an @optional: marker with its list price where it has one, so git grep "@optional: " in any of the three repositories lists the choices.

The running application

In each of dev, staging and prod:

• An AKS cluster, acme-eus2-<stage>-aks, with a private API server, a zonal system node pool and Node Auto Provisioning for the application, plus the add-ons the infrastructure repository installs: the managed NGINX ingress controllers, the External Secrets Operator, cert-manager and ArgoCD.
• The API running as a Kubernetes Deployment, reachable over HTTPS at blueprint-api.<stage>.company.com through Front Door.
• The single-page app at blueprint-app.<stage>.company.com, served by Front Door from a storage static website.
• A Cosmos DB for MongoDB vCore cluster and an Azure Managed Redis cache behind private endpoints, both with Microsoft Entra authentication only.
• An application Key Vault that holds the data-store host names and ports, the Application Insights connection string and the application secrets.
• Application Insights for the stage and, in staging and prod, an availability test on the API's /health endpoint with an alert.
• ArgoCD inside the cluster at argocd.<stage>.internal.company.com, reachable over the VPN and from the self-hosted runners.

The sample application is an items API: list, create, read and delete items in Cosmos DB, with reads cached in Redis for 60 and 300 seconds, and a React dashboard and items page that call it.

The delivery pipeline

• Pull requests to the code repository run lint, unit tests, the front end build, a container build and an image vulnerability scan.
• A merge to main builds the image once, locks its tag in the registry and opens a deploy pull request for dev that merges itself. A change under frontend/ also deploys the React build to dev.
• A GitHub Release tags the same image with its version, deploys it to staging and deploys the front end to staging and, after approval, to prod.
• A manual workflow promotes a release to prod through a pull request that a person merges; ArgoCD in prod then waits for a manual sync.
• Pull requests to the infrastructure repository plan all three stages on the self-hosted runners; a merge applies them, with prod waiting for a reviewer. A daily run reports drift.

The documentation

This documentation set: the architecture, the Kubernetes platform, every unit and module, the GitOps model, the application, the pipelines, the data stores, networking and TLS, security, observability and the guides for day-2 work. The sizing of each stage is on sizing per stage.

What stays with the Baseline

The subscriptions, networks, DNS zones, identities, guardrail policies, security services, the container registry and the self-hosted runners come from the Azure Enterprise Baseline. The blueprint reads what it needs from the Baseline's platform vault in each stage and does not change the Baseline. The architecture overview shows how the two connect.