Skip to content

Why this platform

The problem

An MSP that deploys Azure landing zones for many customers has the same job to do over and over: stand up a compliant landing zone, let a team change it safely, prove what changed, catch drift, and keep costs and policy in view. Doing this by hand does not scale, and most tools that automate it put a third party in the middle of every change.

The approach

This platform runs the entire change workflow inside GitHub Actions and your own Azure tenants. A change is a pull request. Opening it plans the affected infrastructure. A comment applies it. A status check keeps unapplied changes out of the main branch. A daily job reports drift. Policy, security, and cost checks run on every plan.

It is the same review-driven model as Digger or Atlantis, rebuilt from native GitHub Actions and a small set of shell scripts, so there is no orchestrator to run and no vendor in the path of a deployment.

What you get

  • No external control plane

    Everything runs in your GitHub organisation and your Azure tenants. No SaaS orchestrator holds your state, your plans, or your credentials.

  • Data residency by default

    Terraform state stays in your own storage account behind a private endpoint. The only outbound call in the default setup is the infracost pricing lookup, which sends resource region and SKU, never your code.

  • Workload identity, no stored secrets

    Azure access is Entra workload-identity OIDC, scoped per environment. There is no long-lived cloud secret in the repository.

  • Auditable by construction

    Every plan and apply is a comment on a pull request. Every drift is a GitHub Issue. The review history is the audit trail.

  • Repeatable per customer

    One reusable engine and one landing-zone layout. A new customer is a new repo from the template plus a handful of secrets and variables.

  • Guardrails you control

    conftest policy, checkov security, and infracost cost run on every plan. They start advisory and you enforce them when the tenant is ready.

How it fits the Cloud Adoption Framework

The landing zone itself follows the Microsoft Cloud Adoption Framework: a management group hierarchy, a management subscription for platform resources, connectivity, and workload subscriptions that slot underneath. The workflow adds the Well-Architected operational side: change control through review, drift detection, and policy, security, and cost gates that map to the Security and Operational Excellence pillars.

Read on: Architecture.