OpenTofu

Last reviewed Aug 26, 2026 · 704 words

If you already write Terraform, OpenTofu is a rename: install tofu, run it in your existing directory, and your .tf files, providers, modules, and state work without edits. The reason to switch is not a feature. It is that Terraform moved to a source-available BSL licence in 2023 and OpenTofu, a fork under the Linux Foundation, stayed MPL-2.0 with community governance. The features that have since appeared on the OpenTofu side are a bonus, and also the first sign that "drop-in" has a shelf life.

Proxmox VMs and DNS records are the homelab use case

Infrastructure as code sounds like a cloud thing, but the providers a self-hoster actually reaches for are local. The bpg/proxmox provider clones VMs and LXC containers from templates; the Cloudflare and Hetzner providers manage DNS records and tunnels; the Docker provider can hold containers and networks in state; and there is a Gitea provider that creates repositories, organisations, and webhooks so your forge's configuration lives in the forge. A VM definition looks like this:

resource "proxmox_virtual_environment_vm" "immich" {
  name      = "immich"
  node_name = "pve1"

  clone {
    vm_id = 9000
  }

  memory {
    dedicated = 8192
  }
}

tofu init pulls the provider from registry.opentofu.org, tofu plan shows the diff, tofu apply makes it so. The binary itself is a single Go executable that wants about 256 MB of RAM; the resources it manages are the expensive part.

State is where people get hurt

The state file records every resource OpenTofu has created, including attributes like generated passwords and API tokens in plain text. Three rules: never commit terraform.tfstate to Git, store it somewhere shared if more than one machine will run applies, and encrypt it. The third is an OpenTofu-only capability and the strongest argument for it over upstream:

terraform {
  encryption {
    key_provider "pbkdf2" "main" {
      passphrase = var.state_passphrase
    }
    method "aes_gcm" "main" {
      keys = key_provider.pbkdf2.main
    }
    state {
      method = method.aes_gcm.main
    }
  }
}

With that block, the state file on disk or in an S3-compatible bucket is ciphertext. A MinIO bucket on your NAS using the s3 backend is the usual homelab remote state; the passphrase goes in an environment variable, not a file.

Drop-in now, diverging slowly

OpenTofu tracks Terraform's HCL and provider protocol closely enough that the same provider binaries work on both. Where it has gone its own way is state encryption, for_each on provider blocks, early evaluation of variables in backend and module source blocks, and a handful of smaller things. Each of those is a file that upstream Terraform will refuse. The practical advice: choose one tool per repository, write it down in the README, and do not flip between them. If you use an OpenTofu-only feature, you have committed, and that is fine; just know it. The Gitea Actions and Woodpecker CI images both install tofu with one line, so the tooling side of the choice is not the blocker.

Run plans from CI, applies from a button

The workflow that has kept my homelab state sane: every change is a pull request; CI runs tofu fmt -check, tofu validate and tofu plan, and posts the plan as a comment; a merge to main runs tofu apply -auto-approve with the state passphrase and provider tokens as CI secrets. Nobody runs apply from a laptop. That gives you a log of every infrastructure change next to the diff that caused it, and it is the same shape as the compose patterns most homelabs already use for containers. The HCL learning curve is real for a week; the discipline of "plan in CI" is what makes the week worth it.

What I'd do

New setup: OpenTofu, not Terraform, unless your employer's tooling forces the other. Start with one Proxmox VM and one DNS zone in a single repo, remote state in a MinIO bucket with the encryption block from day one, and plans on pull requests in your CI/CD tool of choice. Resist the urge to import your entire existing homelab into state on the first weekend. Import the things you rebuild often and leave the pet servers as pets until you have replaced them.