Introduction to OpenTofu

Why not just click infrastructure together? This module shows the difference between manual configuration and declarative infrastructure code: reproducible, version-controlled, reviewable. You compare OpenTofu with Terraform, Ansible, CloudFormation and Pulumi and understand when to use which tool. We also cover OpenTofu's origins: the fork from Terraform, the MPL 2.0 license, governance by the Linux Foundation, and CNCF Sandbox status since April 2025.

Instead of lengthy theory, you write your first HCL file right away. You learn the building blocks of the configuration language: resource blocks, data blocks, attributes and references. Using the Local Provider, you create files on your system and run through the complete cycle from tofu init to tofu apply. By the end of this block, you read HCL like a familiar language.

Providers connect OpenTofu to the outside world: AWS, Azure, GCP or hundreds of other APIs. You configure your first cloud provider, pin versions in the required_providers block and understand the lifecycle of a tofu plan and tofu apply. You work with the OpenTofu Registry (registry.opentofu.org) and see where it differs from the Terraform Registry: its own signing, its own verification, fully open source.

Hardcoded values make configurations inflexible. You work with input variables, define types (string, number, list, map, object) and set defaults and validation rules. With outputs you make results visible to other modules and the command line, and with locals you avoid repetition. At the end, you refactor your first configuration into a cleanly parameterised version.

Everything you learned comes together: you provision a dedicated VM with security group and elastic IP in the cloud. You use variables for region and instance type, outputs for the public IP, and the OpenTofu documentation as a reference. By the end of the day, your first code-defined infrastructure is running.

State is OpenTofu's memory: without it, the tool doesn't know what exists in the cloud. You understand why state files never belong in Git and configure remote backends with locking. You compare three approaches: S3-compatible with Garage or Ceph RADOS Gateway for on-premise setups, PostgreSQL with advisory locks as a lightweight alternative, and S3 + DynamoDB for AWS environments. You enable versioning for rollbacks and isolate state by environment and component so that a mistake in staging doesn't endanger production.

Terraform stores secrets in state as plain text. OpenTofu solves this natively: since version 1.7, you encrypt state and plan files client-side with AES-GCM before they reach the backend. You configure different key providers (PBKDF2 for getting started, AWS KMS and GCP KMS for production setups, OpenBao as an open-source Vault alternative) and implement key rotation. By the end of this block, your state is encrypted regardless of which backend you use.

Modules are the key to maintainable infrastructure code. You build a custom module with input variables, outputs and internal logic. Then you consume modules from the OpenTofu Registry, pin versions with semantic versioning (~> 1.2.0) and auto-generate documentation with terraform-docs. This is where early variable evaluation comes in: you reference variables directly in source and version of your modules, something not possible with Terraform.

Taking over existing infrastructure, renaming resources or removing them from state: you work with the import block, the moved block and the removed block. These declarative operations are reviewable in pull requests and self-documenting. On top, you learn two OpenTofu-exclusive features: the enabled meta-argument (v1.11) for conditional resource deployment and the .tofu file extension for configurations that only OpenTofu understands.

You build a complete multi-tier infrastructure from reusable modules: VPC with public and private subnets, security groups and a VM in the private network. State is stored remotely and encrypted with AWS KMS, modules are versioned, and the structure follows the conventions from the previous block. At the end, you have a reference architecture with state encryption that you can carry over to your own projects.

HCL can do more than simple assignments. You work with for_each and count for dynamic resource creation, write dynamic blocks for repeated nested structures and use conditionals for environment-dependent configuration. Built-in functions like lookup, merge, flatten and templatefile round out the picture. Here you also go deeper on early variable evaluation: variables and locals in the terraform block, in backend configurations and provider versions.

Code without tests is a promise without proof. You write your first .tftest.hcl files with command = plan for unit tests and command = apply for integration tests. With provider mocking you test modules without cloud credentials. Additionally, you use TFLint for static analysis and tofu validate as a baseline check. At the end, you have a test suite that catches errors before they cost money in the cloud.

sensitive = true masks values in console output but does not protect them in state. Since OpenTofu v1.11, ephemeral resources exist: temporary credentials and tokens that never touch state and only exist during a single phase. You configure ephemeral resources for cloud credentials and supplement them with automated security scanning using Checkov and Trivy, which check your OpenTofu files for misconfigurations and compliance violations.

In production teams, tofu apply does not run from a laptop. You integrate OpenTofu into a CI/CD pipeline with GitHub Actions or GitLab CI: plan as PR comment, apply after approval. Since HCP Terraform only works with Terraform, you learn alternatives: Atlantis (self-hosted), Scalr and env0. In the second part, you migrate an existing Terraform project to OpenTofu: binary swap, verify state compatibility, update registry references and refresh .terraform.lock.hcl.

Everything combined: you build a production-like infrastructure with custom modules, encrypted remote state, variables for environment separation and a test suite. On top, you write a CI pipeline skeleton that runs tofu plan automatically. The result is an OpenTofu project you take home as a template for your own work.