Learn OpenTofu - Complete Production-Grade Enterprise OpenTofu Architecture

#Introduction

In the previous episode 19 we covered Disaster Recovery & Encrypted State Recovery, ensuring that even when a KMS key has problems, infrastructure can still be recovered. Now it's time to tie it all together. Over 20 episodes we've built capabilities one by one — from prerequisites in episode 0 to DR in episode 19 — and in this final episode everything comes together.

In this episode 20, we'll design a Complete Production-Grade Enterprise OpenTofu Architecture. We'll combine the OpenTofu Engine, native client-side state encryption with AWS KMS, dynamic provider iteration, reusable modules, the tofu test framework, Terragrunt and Digger with GitHub Actions OIDC, an OPA policy gate, and automatic drift detection. We'll close with a production readiness checklist and code review guidance.

#The Big Picture of the Architecture

An enterprise architecture isn't about a single tool, but about how tools work together as one system. The production flow becomes:

1. Developers write HCL code inside reusable modules.
2. A PR is opened, and the GitHub Actions pipeline runs: format, validate, and tofu test.
3. Once it passes, a plan is produced and tested against the OPA policy gate.
4. Reviewers approve, merge to the main branch, and apply runs via OIDC.
5. Encrypted state is stored in a remote backend with locking and versioning.
6. A scheduled pipeline checks drift every day and fixes deviations.

Each of these layers was built in previous episodes — now we're just uniting them.

#Foundation: The OpenTofu Engine with State Encryption

The foundation of the architecture is the OpenTofu Engine itself, combined with native client-side state encryption using AWS KMS:

terraform {
  backend "s3" {
    bucket         = "org-opentofu-state"
    key            = "prod/opentofu.tfstate"
    region         = "ap-southeast-1"
    encrypt        = true
    dynamodb_table = "opentofu-state-lock"
  }
 
  encryption {
    key_provider "aws_kms" "main" {
      kms_key_id = "arn:aws:kms:ap-southeast-1:123456789012:key/kms-key"
    }
 
    method "aes_gcm" "main" {
      keys = key_provider.aws_kms.main
    }
 
    state {
      method = method.aes_gcm.main
    }
  }
}

State is stored in S3 with versioning, locked via DynamoDB, and encrypted in two layers: server-side on S3 and client-side by OpenTofu. Even if the bucket leaks, state remains ciphertext that can't be read without the KMS key.

#Dynamic Provider Iteration & Reusable Modules

All resources live inside modules, and providers are configured dynamically to support many regions and environments. As we learned in episodes 7 and 10:

include "root" {
  path = find_in_parent_folders()
}
 
terraform {
  source = "../modules/vpc"
}
 
inputs = {
  env = "prod"
}

With Terragrunt, backends and providers are configured once at the root, then each environment (dev, staging, prod) simply points to the same module — without copying configuration. Dynamic provider iteration completes this so a single module can spread across many regions at once.

#Quality: The Native tofu test Framework

Before code touches the cloud, its quality is assured by OpenTofu's built-in testing framework:

run "bucket_private" {
  command = apply
 
  assert {
    condition     = google_storage_bucket.assets.force_destroy == false
    error_message = "The assets bucket must not force_destroy"
  }
}

This test validates an important invariant — the bucket must not be destroyable by accident. With tofu test, assertions run in the pipeline without requiring an external programming language like Terratest.

#Pipeline: GitHub Actions with OIDC

The entire automated flow runs on GitHub Actions using OIDC — without storing static AWS credentials. The following workflow summarizes the complete enterprise pipeline:

name: opentofu-pipeline
 
on:
  pull_request:
  push:
    branches: [main]
  schedule:
    - cron: "0 6 * * *"
 
permissions:
  id-token: write
  contents: read
  pull-requests: write
 
jobs:
  pipeline:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: opentofu/setup-opentofu@v1
 
      - name: Configure AWS OIDC
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-oidc
          aws-region: ap-southeast-1
 
      - name: Format, validate & test
        run: |
          tofu fmt -recursive -check
          tofu validate
          tofu test
 
      - name: Security scan
        run: checkov -d .
 
      - name: OPA policy gate
        run: |
          tofu plan -out=plan.tfplan
          tofu show -json plan.tfplan > plan.json
          opa eval --data policy/ --input plan.json \
            --fail-defined "data.infra.security.deny"
 
      - name: Apply to production
        if: github.event_name == 'push'
        run: tofu apply plan.tfplan -auto-approve

Notice the three protection layers above: tofu fmt -check and tofu validate for quality, checkov for static security, and the OPA gate for compliance. The apply step only runs on a push event to the main branch — which means every production change has gone through PR review first. Meanwhile, the schedule trigger activates drift detection every morning, as we designed in episode 18.

#Production Readiness Checklist

Before this architecture can be called production-grade, make sure all of the following are satisfied:

• State: remote backend with locking, versioning, and client-side encryption enabled.
• Credentials: no secrets in code; all cloud access via OIDC or a secret manager.
• Modules: all resources organized into reusable modules with clear versions.
• Testing: tofu test runs in the pipeline for every PR.
• Security: Checkov and Trivy scan the code before merge.
• Policy: the OPA gate blocks changes that violate compliance.
• Drift: a scheduled pipeline detects and remediates drift automatically.
• DR: tested recovery procedures run periodically.

#Code Review Guidance for OpenTofu

Infrastructure code review requires a different eye than application review. Some things that must be checked:

• Change effect: does tofu plan show changes matching expectations?
• Destroy: are there any resources about to be destroyed? Use prevent_destroy for critical resources.
• Sensitive data: are secret values marked sensitive = true and never printed?
• Scope: is the change limited to the relevant module?
• Conventions: is tofu fmt clean and are variable names consistent?
• Versioning: are providers and modules pinned to specific versions?

#The 21-Episode Journey

Congratulations — you've reached the final episode. Let's look back at the whole journey:

• Episodes 0-2: prerequisites, environment setup, the fork history from Terraform, and the core workflow tofu init, tofu plan, tofu apply.
• Episodes 3-5: providers, resource declarations, variables, outputs, remote state, and state locking.
• Episodes 6-8: OpenTofu's exclusive features — native client-side state encryption, dynamic provider iteration, plus advanced expressions and loops.
• Episodes 9-11: state manipulation, import workflows, reusable modules, formatting, and the tofu test framework.
• Episodes 12-14: Terragrunt integration, GitHub Actions and GitLab CI pipelines, plus managed platforms and Digger.
• Episodes 15-16: secret management, state hardening, and policy as code with OPA.
• Episodes 17-19: multi-cloud provisioning, drift detection and auto-remediation, and disaster recovery plus encrypted state recovery.
• Episode 20: the production-grade enterprise architecture combining everything.

#Conclusion

In episode 20, we designed a Complete Production-Grade Enterprise OpenTofu Architecture — an encrypted state foundation with AWS KMS, dynamic provider iteration, reusable modules, the tofu test framework, Terragrunt and Digger with GitHub Actions OIDC, an OPA policy gate, and automatic drift detection — closed with a production readiness checklist and code review guidance.

Key takeaways:

• An enterprise architecture is an integration of tools, not just a single tool.
• Encrypted state plus locking and versioning is a non-negotiable foundation.
• Dynamic provider iteration and Terragrunt make multi-environment setups DRY.
• tofu test guarantees quality, Checkov maintains security, OPA maintains compliance.
• OIDC eliminates static credentials from pipelines.
• Automatic drift detection makes infrastructure always converge to the code.
• A disciplined checklist and code review protect production from human error.

Your journey began by running your first tofu init in episode 2, and now ends with the ability to design an architecture on par with what world-class companies use. OpenTofu is proof that fully open-source infrastructure can be the backbone of production — without lock-in, without hidden license costs, and with a community that keeps growing.

Thank you for sticking through to episode 20. Don't stop here — apply what you've learned to real projects, share your knowledge with fellow engineers, and keep building. See you in the next series!