Provisioning

Reply CMP Provisioning lets you define cloud resources once and deploy them across your connected providers—safely, consistently, and with full lifecycle control.

Note

Provisioning manages infrastructure. For costs, budgets, and allocations see FinOps.

Quick start

  1. Create a Deployment (a logical container for resources).

  2. Attach one or more cloud Connections (for example, one Azure connection and one AWS connection).

  3. Add Resources from the catalog and fill in their properties.

  4. Run a Dry run (terraform plan) to preview changes.

  5. Apply to provision or update resources in your clouds.

Tip

Use small, focused deployments (by app, environment, or team) to keep plans readable and applies fast.

How it works

Provisioning is built around two concepts: Deployments and Resources.

  • Deployment: a named workspace that groups related resources and tracks their state.

  • Resource: a single cloud service instance (for example, Azure Virtual Network, AWS EC2 Instance) defined by typed metadata.

Connections bind your tenant to specific provider scopes (Azure subscription, AWS account, GCP project, …). A deployment can use multiple connections, but not more than one of the same type (for example, only one Azure connection per deployment).

Important

State storage: Each deployment stores a dedicated Terraform state (tfstate) in a private Azure Storage account managed by Reply CMP. Data at rest is encrypted (AES‑256), data in transit uses HTTPS, and the storage account is not exposed to the public internet. Replication options protect against data loss (for example, GRS).

See Microsoft’s guidance for details on Azure Storage security.

See also

After an apply, your resources appear in Discovery with a “Provisioned via CMP” link back to this deployment. Use Discovery to inspect properties, relationships, and change History over time.

Catalog and validation

Resources are created from catalog items. Each catalog item ships with a JSON Schema describing required and optional properties. When you save a resource, its metadata is validated against that schema to catch errors early—before any apply.

Note

Catalog customization: On request, Reply CMP can add new catalog items or extend existing ones (fields, defaults, validation rules). Contact your CMP administrator or your Reply CMP contact point to discuss requirements and timelines.

Create a deployment

  1. Open Provisioning → New Deployment.

  2. Enter a name and location (just a logical one, not mapped to cloud providers’ locations).

  3. Attach connections you’ll deploy to. You can add more later; you can’t edit an attached connection, only add/remove.

  4. Save. New deployments start in status Valid.

Note

“Valid” means the last apply (if any) finished successfully. New deployments are Valid because no changes are pending.

Add resources

  1. Inside the deployment, choose Add Resource.

  2. Pick a catalog item (for example, Azure Virtual Network, AWS EC2 Instance).

  3. Fill the metadata fields; required fields are enforced by schema.

  4. Save. The resource status is Draft until applied.

Tip

To speed up similar resources, duplicate an existing resource and only adjust the parameters that differ (for example, name, tags, or size). This keeps consistency and reduces errors.

Dry run (plan) vs Apply

  • Dry run: Runs terraform plan for the whole deployment and produces a human‑readable diff. State and cloud resources are not changed.

  • Apply: Runs terraform apply for the whole deployment, creating/updating/deleting as needed.

After a Dry run or Apply, Reply CMP shows an AI‑generated summary to highlight impactful changes.

Warning

Applies affect all resources in the deployment. If you only want to update a subset, consider splitting into multiple deployments.

Deployment statuses and deletion

  • Valid: Last apply succeeded; tfstate matches cloud configuration.

  • Error: Last apply failed; review errors and re‑apply when fixed.

  • Tainted: The deployment was successfully applied with no resources and is now eligible for deletion.

Deletion rules:

  • To delete a deployment, it must be Tainted.

  • A deployment becomes Tainted by applying when it contains no resources.

  • If a deployment has resources (or never had a clean no‑resource apply), deletion is blocked.

Resource lifecycle

  • Create: Define metadata; status is Draft; latestAppliedMetadata is null.

  • Update: Edit metadata; status returns to Draft. Drift is the difference between metadata and latestAppliedMetadata.

  • Apply: On successful apply, status becomes Valid and latestAppliedMetadata aligns to metadata. On failure, neither field changes.

  • Delete: Deleting a resource in the UI schedules its removal; the actual deletion occurs on the next apply.

  • Rollback: Each metadata change is versioned in the activity log. Select a prior version, restore, and apply to revert the resource.

Note

Drift detection: If the cloud configuration changes out‑of‑band, you’ll see differences between metadata and what Discovery captures in the resource History. Align metadata and re‑apply to converge.

Error handling

If an apply fails, the deployment enters Error. The details panel shows the provider errors and an AI‑generated explanation with likely causes and suggested fixes (for example, missing permissions, invalid CIDR, resource name conflicts). After you correct the issue, run Apply again. A successful apply returns the deployment to Valid.

Best practices

  • Keep deployments scoped to one app or environment to reduce blast radius.

  • Prefer tags and naming conventions that match your FinOps allocation rules.

  • Validate with Dry run before Apply in production environments.

  • Avoid hard‑coding credentials or secrets in metadata; use connection‑level identities and variables where available.

  • Break large changes into smaller applies to simplify troubleshooting.

FAQ

Can I attach multiple cloud providers to the same deployment?
Yes. You can mix providers by attaching different connection types. You cannot attach more than one connection of the same type to a single deployment.

Where is state stored? Can I bring my own backend?
State is stored in a private Azure Storage account managed by Reply CMP. Bring‑your‑own backends are not supported at this time.

What happens if a plan shows unexpected changes?
Investigate metadata drift and out‑of‑band changes in the cloud. Align metadata or import resources as appropriate, then re‑plan.

Can I request new catalog items or custom fields?
Yes. Reach out to your CMP administrator or Reply CMP contact point. We can add new items or extend schemas (properties, defaults, validation) to fit your needs.

Can I delete a deployment directly?
Only when it is Tainted. Apply a no‑resource state first, then delete.

Glossary

  • Deployment: A workspace grouping resources and holding state.

  • Resource: A typed cloud service instance defined by metadata.

  • Connection: A binding to a provider scope (subscription/account/project).

  • Metadata: The user‑defined properties for a resource.

  • latestAppliedMetadata: Snapshot of metadata at the last successful apply.

  • Dry run (plan): A preview of changes without applying them.

  • Apply: Executes changes against the cloud and updates state.

  • Tainted: Deletion‑ready deployment state after a successful no‑resource apply.