Module registry#

The Module registry contains the Terraform modules that can be used to create Resources. Tenant modules come from your Git repository; Reply CMP-managed modules are maintained by the platform team.

Navigate: left navigation → Provisioning → Module registry.

Understand the registry#

A module record represents one reusable Terraform folder. A version represents one immutable, reviewed commit of that folder.

For example, a monorepo with these paths needs three registrations:

modules/network
modules/storage
modules/database

All three records can use the same repository and credential, but each has its own versions and approvals.

Add a credential#

Open Credentials → Add credential when the repository is private or Reply CMP must start a customer runner.

Type

Use it for

Azure DevOps PAT

Read an Azure DevOps repository and start the selected pipeline.

GitHub fine-grained token

Read and dispatch one or more explicitly selected repositories.

GitHub App

Organisation-managed GitHub access with central installation and key rotation.

Enter the secret once and optionally choose its next rotation date. Reply CMP stores it in the tenant vault; the value is never returned to the UI or passed to Terraform.

Add provisioning credential panel with credential name, type, token and rotation date

Use a purpose-based name so operators can identify where the credential is used.#

Rotate replaces the secret without changing references from modules or Deployments. Revoke prevents new repository reads and runner dispatches. Remove a credential record only after nothing uses it.

Register one module#

Select Register module and complete the three sections.

1. Identify the module#

Field

What to enter

Module name

Stable lowercase identifier, for example network-hub.

Display name

Friendly catalogue name, for example Network hub.

Cloud provider

Azure, AWS or GCP.

Source provider

Azure DevOps or GitHub.

Description

What the module creates and when a team should use it.

2. Connect the source#

Field

What to enter

Canonical repository URL

Repository root, not a branch or folder URL.

Module path

Folder relative to the repository root. Leave empty only when the module is at the root.

Default ref

Protected branch or tag proposed for the next version.

Repository credential

An active matching credential, or empty for a public repository.

3. Describe the inputs#

Initial JSON Schema defines the first guided Resource form. A later immutable version uses the schema.json committed in the selected module folder as its authoritative schema.

Register tenant module panel with identity, repository source and input schema sections

One registration represents one module path, even when the repository contains many modules.#

Prepare the module folder#

The registered folder must contain:

  • Terraform .tf files;

  • schema.json describing the user-editable module input;

  • .terraform.lock.hcl containing checksums for every provider used by the module;

  • root variables environment, tenant_id, deployment_name, location and resource_name.

Create provider locks from that exact folder and commit the result:

terraform providers lock
git add .terraform.lock.hcl
git commit -m "Lock Terraform providers"

The current module contract requires Terraform 1.15.8. Provider configuration and credentials belong to the runner, not inside the reusable module.

Important

Do not type provider checksums into Reply CMP. The platform reads schema.json and .terraform.lock.hcl from the exact selected commit and validates them automatically.

State, plan, tfvars, certificate, private-key, .git and .terraform files are rejected from module archives.

Prepare a module with an AI coding assistant#

Reply CMP provides two optional Agent Skills for repositories maintained with GitHub Copilot, Claude Code, Codex or another compatible coding assistant. A skill contains reviewable instructions only: it does not receive Reply CMP credentials and it must never run Plan or Apply.

Skill

Use it when

Generate Reply CMP schema

The Terraform inputs already exist and you want the assistant to create or repair schema.json.

Author a Reply CMP module

You want the assistant to prepare or review the complete module folder, including platform inputs, provider locks and prohibited patterns.

Extract the selected ZIP into the project skill directory used by your assistant:

Assistant

Project location

Codex

.agents/skills/<skill-name>/

GitHub Copilot

.github/skills/<skill-name>/ or .agents/skills/<skill-name>/

Claude Code

.claude/skills/<skill-name>/

Commit the skill with the repository so module owners and reviewers use the same contract. Then ask the assistant, for example: Use reply-cmp-generate-schema to generate schema.json for this module. Always review the Terraform and generated schema before registering a version.

Add and approve a version#

Open the module and select Add version.

  1. Choose repository source.

  2. Enter a new semantic version such as 1.2.0.

  3. Enter a protected tag or branch. A protected tag is recommended for releases.

  4. Keep Terraform version 1.15.8.

  5. Submit the version.

  6. Open the version and review its exact commit, source link, schema, connected credential or public-source status, provider locks and validation result.

  7. Approve it when the evidence is correct.

State

Meaning

Pending

Validation passed and review is required.

Approved

The version can be selected by new or existing Resources.

Rejected

Review was closed with a reason; create another version from corrected source.

Revoked

New use is blocked while history remains visible.

Approval and revocation never rewrite an existing version. If a branch later moves, the approved version remains pinned to the original commit and content digests.

Update one Resource to another version#

Approving a new module version does not upgrade existing Resources automatically.

  1. Open Deployments → your Deployment → Resources.

  2. Open the Resource to update.

  3. Select Change module version.

  4. Choose an approved version and review the read-only version details.

  5. Complete any new required inputs. Existing compatible values are carried forward.

  6. Save the Resource. Only this Resource becomes Draft.

  7. Create a fresh Plan and review replacements and deletes before Apply.

Repeat this process only for the Resources that should adopt the new version.

Starter repositories#

The starter packages contain a valid example module, schema, provider lock and the complete runner contract.