Introduction to OpenTofu

Infrastructure as code describes infrastructure declaratively in versioned configuration. You compare OpenTofu with Terraform, Ansible, CloudFormation, and Pulumi and distinguish provisioning, configuration management, and platform-specific approaches. Origins, governance, and licensing models provide decision context without becoming a general product recommendation or permanent compatibility promise.

An OpenTofu configuration combines blocks, arguments, and expressions in HCL. You examine resource and data blocks, attributes, and references and use the local provider for a self-contained first example. You then run tofu init, plan, and apply and trace the files and state OpenTofu creates along the way.

Providers translate configuration into API calls for the connected platform. You define required_providers, set version constraints, and read the dependency lock file. You then examine sources, signatures, and verification in the OpenTofu Registry and clearly distinguish technical provenance checks from informed approval of a provider.

Input variables make configurations adaptable but require clear types and boundaries. You define scalar and structured types, defaults, and validation rules and use outputs for selected results and module handovers. With locals, you group derived values and refactor the existing configuration without expanding its interfaces unnecessarily.

The DevNinjas Dojo, our cloud learning environment, connects providers, variables and references through a cloud scenario. You model a VM, a security group and a public or elastic IP and use outputs for selected connection data. The OpenTofu documentation and plan output support the work but do not replace informed approval.

State maps configured resources to their remote objects and requires controlled write access. You compare backend configurations for S3-compatible targets such as Garage and Ceph RGW, PostgreSQL with advisory locks, and AWS S3. You examine backend-specific locking, versioning, permissions, and environment separation rather than assuming universal interchangeability.

OpenTofu can encrypt state and plan files on the client before storing them. You configure AES-GCM, compare PBKDF2 with key providers for AWS KMS, GCP KMS, and OpenBao, and keep key material out of configuration. Fallback and rotation settings show how key changes must be planned and tested before production use.

Modules encapsulate resources behind defined inputs and outputs. You develop a custom module, consume a component from the OpenTofu Registry, and document interfaces with terraform-docs. Version constraints and early variable evaluation in a module source or version, available since OpenTofu 1.8, are treated as powerful tools with explicit dependency and review boundaries.

Existing resources, changed addresses, and deliberate removals require transparent state operations. You work with import, moved, and removed blocks and examine their effect in a plan. You then investigate the enabled meta-argument for conditional resources, available since OpenTofu 1.11, and examine how .tofu files, supported since 1.8, take precedence over same-named .tf files.

A coherent scenario connects module boundaries, remote state, encryption, and networking concepts. You design a VPC with public and private subnets, security groups, and a VM in the private network and include AWS KMS as a key provider. In the lab, you inspect interfaces, versions, and key dependencies without presenting them as a transferable reference architecture.

Expressions control how OpenTofu derives values and describes repeated resources. You compare for_each and count, dynamic blocks, conditionals, and functions such as lookup, merge, flatten, and templatefile. You also examine early variables and locals in module sources, backend, and encryption configurations and assess their effect on transparent dependencies.

OpenTofu tests describe runs and assertions in .tftest.hcl files. In this process, you compare plan and apply runs and use provider mocking for suitable module tests since OpenTofu 1.8. tofu validate and TFLint complement these tests with syntax, schema, and static checks but cannot cover every runtime effect.

Values marked as sensitive are redacted in output but can still remain in state. You configure the ephemeral resources available since OpenTofu 1.11 for temporary cloud credentials within the resource types supported by the selected provider. You also use Checkov and Trivy for configuration scans and treat findings as review signals rather than automatic approval.

CI can provide repeatable checks but requires deliberate permission and approval boundaries. You outline a workflow with GitLab CI or GitHub Actions and compare automation platforms such as Atlantis, Scalr, and env0. For a Terraform migration, you back up state and configuration, initialise OpenTofu, and review provider sources, registry references, the lock file, plan, and tests.

Finally, you connect modules, encrypted remote state, environment variables, tests, and a CI-supported plan in one scenario. You trace dependencies from the key provider to the pipeline and examine which decisions remain project-specific. The exercise supports transfer of the concepts and is not a production-ready system or binding operating model.