Provisioning overview#

Provisioning lets teams create cloud resources from approved Terraform modules while the customer keeps control of execution identities, runner logs and Terraform state.

Navigate: left navigation → Provisioning. Its submenu contains Deployments, Module registry and Policy guardrails.

How Provisioning works#

Reply CMP prepares and governs each operation. Terraform runs in the customer’s Azure DevOps pipeline or GitHub Actions workflow. State remains in the customer’s Azure Blob container.

Reply CMP sends an immutable operation to a customer runner, evaluates guardrails and keeps Terraform state in customer-owned Azure Blob storage

Reply CMP controls intent and evidence; the customer controls execution and state.#

The normal flow is:

  1. A module owner registers one Terraform module and approves an immutable version.

  2. A deployment owner creates a Deployment and connects its cloud accounts.

  3. The owner selects an Azure DevOps or GitHub runner and an existing Azure Blob container for state.

  4. Resources are added from approved module versions.

  5. Plan runs in the customer runner and is evaluated by platform and tenant guardrails.

  6. Apply creates a fresh plan, evaluates it and applies that exact saved plan.

The objects you manage#

Object

What it represents

Module

One Terraform module in one repository path.

Module version

One reviewed semantic version pinned to an exact commit, input schema and provider locks.

Deployment

A group of Resources that share cloud connections, one runner and one state file.

Resource

One configured instance of an approved module version.

Policy guardrail

A versioned rule checked against every exact plan before Apply.
An approved module version becomes a configured resource, then passes through Plan, policy evaluation and Apply

Changes move from reviewed source to cloud through a traceable Plan and Apply lifecycle.#

What Reply CMP stores#

Reply CMP stores configuration, version references, structured plan results, policy decisions and operation evidence. It does not store raw Terraform state or copy the complete Terraform log from the customer runner.

Long-lived repository and dispatch credentials are stored in the tenant vault and are never returned to the browser. Terraform and runtime callbacks use short-lived workload identity federation.

Where to start#

First setup

Prepare a starter repository, register a module, connect a runner and state, then create the first Resource.

Follow the quickstart →

Modules

Register repository paths, manage credentials and approve immutable versions.

Manage the Module registry →

Runner and state

Configure Azure DevOps or GitHub and connect an existing protected Azure Blob container.

Configure Runner & state →

Daily operations

Add Resources, review Plan results, open runner logs and run Apply.

Manage Deployments →

Safety guarantees#

  • Source refs are resolved to exact commits before a module version is approved.

  • Provider packages must be checksum-locked in .terraform.lock.hcl.

  • Terraform is pinned to the reviewed Reply CMP release. The current contract uses 1.15.8.

  • Every Deployment receives its own deterministic state key.

  • State requires Microsoft Entra authentication, TLS 1.2 or later, Blob versioning and at least 14 days of Blob and container soft delete.

  • Apply can run only after guardrails accept the exact plan recorded for that operation.