Terraform modules for IBM Cloud: AI-ready building blocks for cloud infrastructure

AI is changing how teams build their cloud infrastructure. But whether you're writing Terraform-based solutions by hand or generating them with an AI assistant, the hard problems are the same: Which service-to-service authorizations do you actually need? What are the encryption defaults? How do you set auto-scaling thresholds that won't wake you up at 3am? How do you configure fine-grained context-based restrictions? What edge cases will cause issues in production?

These aren't coding problems. They're knowledge problems. And that knowledge comes from months of research, failed deployments, and lessons learned the hard way. Every engineer doing this independently rediscovers the same answers. Every departure takes institutional knowledge with them. AI can help, but the quality of what it generates depends on the building blocks you give it. When those building blocks are supported, kept up to date, and backed by a team that's accountable for them, that matters even more in a world where AI is assembling your infrastructure.

The terraform-ibm-modules project captures that knowledge as composable building blocks for IBM Cloud. These production tested, IBM supported modules are built from years of configuring IBM Cloud services correctly. The value is the same whether you're working by hand or with an AI assistant: compose from supported, maintained modules instead of building from scratch. Pick the modules you need, wire them together, and get infrastructure that's already configured the way IBM's own engineers would configure it. The difference is just how you do it, manually or conversationally.

These modules build on Terraform, using the IBM Cloud provider, and following best practices for Terraform on IBM Cloud.

What you get

terraform-ibm-modules are IBM Cloud’s supported Terraform modules. They’re not community experiments or proof-of-concepts. You get IBM support, consistent module patterns, and tests run on every release. If something breaks, IBM owns the fix.

IBM started developing these modules in 2021 to build infrastructure for core IBM Cloud services. That internal usage continues to refine them through production deployment. They now power infrastructure for major IBM Cloud customers, and are also the building blocks for IBM solutions such as the landing zone deployable architectures.

This matters if you're in a larger organization. Security and compliance teams audit the modules once, not every project's custom implementation. Platform teams curate approved modules. Development teams compose infrastructure from those approved building blocks. You get fast deployment within guardrails.

The collection includes 90+ actively maintained modules with over 13.8 million total downloads, spanning account setup, VPC networking, IBM Cloud Databases, security services (Key Protect, Secrets Manager, SCC WP), container platforms (OpenShift, Code Engine), observability, watsonx, and more.

Every module follows the same structure:

terraform-ibm-{service-name}/
├── main.tf
├── variables.tf
├── outputs.tf
├── versions.tf
├── modules/
│   └── fscloud/          # Financial Services Cloud variant
├── examples/
│   ├── basic/
│   └── complete/
│   └── ...
└── tests/

Learn one module, and you know them all.

How modules combine

An encrypted database needs a KMS key. That's the kind of dependency these modules handle cleanly:

module "kms" {
  source  = "terraform-ibm-modules/kms-all-inclusive/ibm"
  version = "5.5.27"
  # ... creates Key Protect instance and encryption keys
}

module "postgresql" {
  source      = "terraform-ibm-modules/icd-postgresql/ibm"
  version     = "4.8.0"
  name        = "my-postgresql"
  region      = "us-south"
  kms_key_crn = module.kms.keys["db-keys"]["postgresql-key"].crn
}

One module's output feeds into another module's input. Standard Terraform. You control composition, dependencies, variables, and state. The modules handle IBM Cloud complexity (service authorizations, encryption configuration, endpoint policies), and you just handle architecture.

Each module's examples directory shows real compositions. The complete examples wire together multiple modules with all the options you'd want in production.

The modules worth knowing

For the complete catalog of IBM Terraform modules, see the Terraform Registry. Here is a a short, representative list (which is not exhaustive):

• terraform-ibm-iam-account-settings configures account-level IAM policies and MFA. terraform-ibm-cbr creates Context-Based Restrictions to control network access.
• terraform-ibm-landing-zone-vpc handles VPC foundations. The terraform-ibm-landing-zone module wires together management and workload VPCs via Transit Gateway.
• The database modules (PostgreSQL, MongoDB, Redis, MySQL, Elasticsearch) share a uniform interface. All support KMS encryption, backup encryption, auto-scaling, and deletion protection.
• For key management, terraform-ibm-kms-all-inclusive covers Key Protect or HPCS. terraform-ibm-secrets-manager handles secrets, and terraform-ibm-scc-workload-protection handles Security and Compliance Center.
• For OpenShift clusters, terraform-ibm-base-ocp-vpc.

Financial Services compliance are built in

For regulated industries, fscloud submodules matter. These pre-configured variants implement IBM Cloud Framework for Financial Services: 565 control requirements from NIST 800-53, validated by financial institutions.

What fscloud enforces: KMS encryption (no IBM-owned keys), private endpoints only, Context-Based Restrictions pre-configured.

module "mongodb_fscloud" {
  source            = "terraform-ibm-modules/icd-mongodb/ibm//modules/fscloud"
  version           = "3.12.0"
  resource_group_id = var.resource_group_id
  name              = "compliant-mongodb"
  region            = "us-south"
  kms_key_crn       = var.hpcs_key_crn
}

Submodules exist for databases, COS, CBR, CIS, and IAM account settings. You configure compliance instead of spending months engineering it.

Testing and maintenance

Every module release passes automated validation: idempotency checks, breaking change detection, and deployment validation against IBM Cloud. Before release, multiple engineers review the code to catch design issues automated tests miss.

The testing framework is open source: ibmcloud-terratest-wrapper wraps Gruntwork's Terratest with IBM Cloud capabilities. Use it for your own modules.

A dedicated IBM Cloud team maintains the modules and updates them as Terraform, IBM Cloud services, and compliance requirements like the IBM Cloud Framework for Financial Services change.

Open source collaboration

The terraform-ibm-modules project is open source. Fork repositories, make enhancements, submit pull requests. All contributions follow the contribution guidelines.

The community gets IBM's testing and maintenance. IBM gets real-world usage patterns and contributions back.

AI-assisted composition

The terraform-ibm-modules MCP server connects AI assistants like Claude or GitHub Copilot directly to the module catalog using the Model Context Protocol (MCP). Instead of generating Terraform from its general training data, the AI composes from modules that are tested, versioned, and maintained by a dedicated team.

Describe what you need. The AI suggests module combinations, wires dependencies, and generates configurations. You still own the Terraform code, and every component in it has a team behind it and a test suite that runs before each release.

Also worth watching: the terraform-ibm-modules skills repository, an experimental collection of IBM Cloud-specific patterns and best practices that AI assistants can learn from. It's still early, but the goal is to teach AI not just what modules exist, but how to use them well.

The payoff

Building secure, compliant cloud infrastructure from scratch takes months. These modules let you skip most of that.

A secure OpenShift cluster with VPC, IAM, KMS, COS, and observability normally takes roughly 1,500 lines of Terraform. Using terraform-ibm-modules, it's under 200. But line count isn't the real win. These configurations have been validated across thousands of deployments and reviewed by security teams. You know the code works because it's already running in production elsewhere.

For organizations, that translates to faster time to production and simpler audits. Updates flow through the module library as IBM Cloud evolves.

Following IBM's acquisition of HashiCorp in February 2025, these modules sit at the intersection of IBM's two main infrastructure automation tools: Terraform for provisioning, Ansible (via Red Hat) for configuration management. Organizations already using terraform-ibm-modules are well positioned as IBM integrates these tools more tightly.

You keep full Terraform control while benefiting from decisions already made well.

Getting started

Browse the module catalog in the IBM Cloud docs, the GitHub organization, or the Terraform Registry. Each module includes documentation and examples. For compliance, start with fscloud submodules. Or, use the MCP server with your AI assistant to explore modules conversationally.

Run with Terraform CLI (standard init/plan/apply), IBM Cloud Schematics, HashiCorp Terraform Cloud, or any CI/CD pipeline. Also, the documentation repository has contribution guidelines.