Manage Deployments#

A Deployment is the Reply CMP workspace that groups cloud Resources, binds Connections (with aliases), and holds the Terraform state for everything it contains. This page covers Deployment-level management: creating, configuring, operating, and deleting Deployments.

Note

This page is about managing Deployments as containers. For managing the individual cloud Resources inside a Deployment (adding, editing, rolling back), see Add Resources from Catalog.

Navigate: left navigation → Provisioning → select an existing Deployment from the list.

Core concepts#

Provisioning is built around two distinct objects: Deployments and Resources.

Object

What it is

Deployment

A named Reply CMP workspace. Groups Resources, binds Connections, holds Terraform state. Does not correspond to any single cloud object.

Resource

A single cloud service instance (e.g. Azure VNet, AWS S3 bucket) defined by typed metadata inside a Deployment.

Important

A Deployment and a cloud resource (infrastructure) are not the same thing. The Deployment is the Reply CMP container that manages one or more cloud Resources. Each Resource inside the Deployment maps to one real piece of infrastructure.

Connections and aliases#

Connections bind your tenant to specific provider scopes (Azure subscription, AWS account, GCP project). A Deployment can use multiple connections from different providers, and also multiple connections of the same provider type by using aliases:

  • The first connection of a given type automatically receives the alias default.

  • Additional connections of the same type require a custom alias (for example, dev, prod, us-east, eu-west).

Aliases map directly to Terraform provider aliases, enabling Resources to target different subscriptions, accounts, or projects within a single Deployment.

Important

State storage: Each Deployment holds 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.

See Microsoft’s guidance on Azure Storage security.

Deployment list#

The Deployments list shows one row per Deployment (not per Resource):

Column

Description

Name

The Deployment’s display name

Connections

Provider badges and aliases attached to this Deployment

Resources

Count of Resources defined inside the Deployment

Status

Current Deployment status badge

Last applied

Timestamp of the most recent apply

Deployment status lifecycle#

A Deployment’s status reflects the outcome of the last apply operation—it is independent of the status of individual Resources inside it.

Status

Meaning

Valid

The last apply succeeded; the Terraform state matches the desired cloud configuration

Error

The last apply failed; review errors in the details panel and re-apply when fixed

Tainted

Successfully applied with no Resources; the Deployment is now eligible for deletion

Note

Draft is a Resource status, not a Deployment status. When you add or edit a Resource inside a Deployment, that Resource moves to Draft. The Deployment itself stays Valid (or Error) until the next apply changes its outcome.

Creating a deployment#

  1. Open Provisioning → New Deployment.

  2. Enter a name and location (a logical label—not a cloud provider region).

  3. Attach the Connections you will deploy to:

    • The first Connection of each provider type receives the alias default.

    • Additional Connections of the same provider type require a custom alias (for example, dev, prod).

  4. Save. New Deployments start in status Valid.

You can add more Connections after creation. You cannot edit an attached Connection—only add or remove it.

Editing a deployment#

You can rename a Deployment or manage its Connections:

  1. Open the Deployment → click Edit.

  2. Change the name or add/remove Connections.

  3. Save.

Note

Editing a Deployment’s connections does not trigger a plan or apply. Connection changes take effect the next time you run Apply.

To modify a Resource’s configuration (not the Deployment itself), see Deploy from Catalog.

Running dry run and apply#

Dry run and Apply operate at the Deployment level: they evaluate and execute changes for all Resources contained in the Deployment.

Operation

What it does

Dry run

Runs terraform plan; shows a human-readable diff of what would change. State and cloud resources are not modified.

Apply

Runs terraform apply; creates, updates, or deletes cloud resources as needed. Deployment status updates on completion.

After either operation, Reply CMP shows an AI-generated summary of impactful changes.

Warning

An Apply affects all Resources in the Deployment. If you only need to update a subset, consider splitting into multiple Deployments.

Apply history#

The History tab on a Deployment detail page shows the timeline of all apply operations for that Deployment:

  • Timestamp and applied-by user for each apply.

  • High-level outcome (success / failure).

  • Link to the apply log and AI summary.

For per-Resource version history and rollback, see the Resource activity log.

Drift detection#

Reply CMP compares the Terraform state (what was last applied) against the live infrastructure discovered by the platform. Drift is flagged when:

  • A cloud resource property was changed outside of Reply CMP (for example, a VM was resized in the Azure portal).

  • A cloud resource was deleted outside of Reply CMP.

When drift is detected, the Deployment card shows a Drift Detected badge. Clicking it shows the diff between the desired state and the current live state.

Resolution options:

Option

Effect

Re-apply

Overwrites the live resource with the Reply CMP desired state (runs Apply)

Sync

Updates the Reply CMP state to match the current live resource (imports the current live state)

Downloading the Terraform state#

For advanced debugging, the raw tfstate is downloadable from the Deployment detail page:

Advanced tab → Download state file → saves terraform.tfstate locally.

Warning

The tfstate file may contain sensitive values (credentials, connection strings). Handle it with appropriate security controls and do not commit it to source control.

Deleting a deployment#

A Deployment can only be deleted when it is in Tainted status. The steps to reach Tainted are:

  1. Remove all Resources from the Deployment in the UI (see Deploy from Catalog).

  2. Apply — with no Resources, Terraform destroys any remaining cloud objects and clears the state. The Deployment enters Tainted status.

  3. Delete the Deployment from the list.

Note

Post-delete: cost data for the decommissioned Resources remains visible in FinOps history and Analyze views for audit purposes.

Warning

If the Deployment still has Resources (or was never successfully applied in a no-resource state), deletion is blocked. Remove all Resources and apply first.

Best practices#

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

  • Use connection aliases meaningfully (for example, prod, staging, us-west, eu-central) to make Resource targeting clear.

  • 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.

Related pages#