Azure Container Apps Terraform Stack

A Terraform-provisioned Azure Container Apps environment running backend, frontend, and an internal-only Redis cache, wrapped in a CI/CD pipeline that builds, promotes, and deploys every release without manual deployment commands.

I designed and built this end-to-end on my own: the Terraform infrastructure, the per-container ingress and cost controls, and the CI/CD pipeline that takes a build from source through release-candidate, QA, and stable promotion to a live environment.

Deploying multiple apps into a single container environment by hand means configuring secrets, environment variables, per-app settings, and ingress rules separately for each one, and every one of those is a place a human error can creep in; tracking down which manual step caused a given issue wastes real engineering time.

The problem compounds when a single product is made up of multiple containers, each with its own configuration. Repeating that setup correctly, every time, without drift or mistakes, isn't something manual deployment can reliably guarantee.

1. Started by understanding how the application worked locally, working out what each component needed to run, then containerized every part of it.

2. Ran the containers on a local container engine first to catch issues before touching any cloud infrastructure.

3. Decided to build a Terraform project to deploy the containerized app on Azure Container Apps.

4. Used that Terraform project to provision every resource from scratch where it didn't already exist: a resource group, a virtual network with a dedicated subnet delegated to Microsoft.App/environments (required for Container Apps VNet integration), a Log Analytics Workspace (a hard requirement for any Container Apps environment), and the Container Apps Environment itself. Authenticated using a Service Principal rather than interactive az login, specifically because I knew this project would eventually need to run unattended inside a CD pipeline, not just from a developer's machine.

5. Structured the Terraform code around two kinds of modules: single-purpose modules for common resources I'd reuse elsewhere (modules/general for the resource group, modules/network for the VNet and subnets), and a separate combination module (modules/con-app) designed as a factory for stamping out a full container-app resource group as one repeatable unit. That factory module is scaffolded but not yet wired into the root module (the root currently provisions the three container apps directly), so it's a deliberate next step rather than a finished part of the design.

6. Restricted ingress so only the frontend is reachable from outside the environment; backend and Redis are both internal-only, accessible exclusively from within the Container Apps environment, with no direct external path to either.

7. Configured the container apps to scale to zero when idle, so cost tracks actual usage instead of paying for always-on compute.

8. Wired runtime configuration automatically instead of by hand: the backend's Redis connection string and the frontend's backend address are both injected by Terraform from the actual deployed resource names, and secrets are sourced from tfvars/CI, with secret keys transformed to valid Container Apps naming automatically.

9. Built a CI pipeline that containerizes every component of the app and pushes the resulting images to Azure Container Registry, tagged as a release candidate.

10. Built a CD pipeline where the Dev stage deploys the release-candidate image automatically, the QA stage requires someone with the right permissions to trigger deployment to the QA environment, and once QA passes, a manually-triggered stage retags the image from release-candidate to stable and pushes that tag to the registry.

11. Added a final stage that runs the same Terraform project with the latest stable image, provisioning a new environment if none exists or updating the existing one in place if it does, so there's a single deployment mechanism for both first deploy and every update after it.