Docs / Build your stack

OpenTofu

OpenTofu is the tool TractorStack uses to describe virtual machines, disks and networks as code. You write what should exist, run tofu plan to see the difference between that and what is actually there, and tofu apply to make the change. It works against the API of your hypervisor, so nothing is clicked together by hand.

Why OpenTofu and not Terraform

In August 2023 HashiCorp moved Terraform from an open-source licence to the Business Source License. OpenTofu was forked from the last open version and is now run under the Linux Foundation with the MPL-2.0 licence. For a platform that customers keep and run themselves, we want every building block under a licence that won’t change under them. The configuration language is close to Terraform’s, so most existing knowledge and many modules carry over, though the two projects are slowly diverging.

Role in each stage

On Proxmox VE the design uses a community provider such as bpg/proxmox. On VMware vSphere it uses the vSphere provider published as hashicorp/vsphere. Network pieces such as VLANs and DNS records will be handled by OpenTofu where the device has a usable provider, and by Ansible where it doesn’t.

State stays on-site

OpenTofu keeps a state file that records what it created. TractorStack is planned to store it in the customer’s own PostgreSQL through the built-in pg backend, which also gives locking so two people can’t apply at once. Since OpenTofu 1.7 the state can be encrypted on the client before it is written, so a database dump doesn’t expose disk paths, IP addresses or any secrets that ended up in state.

Planned configuration

A short illustrative example of what tofu/backend.tf could look like. This is a planned example, not code from a release.

# Planned example only
terraform {
  backend "pg" {
    # connection string read from the PG_CONN_STR environment variable
    schema_name = "tofu_prod"
  }
  encryption {
    key_provider "pbkdf2" "main" {
      passphrase = var.state_passphrase
    }
    method "aes_gcm" "main" {
      keys = key_provider.pbkdf2.main
    }
    state { method = method.aes_gcm.main }
  }
}

Feeding Ansible

Each VM’s name, address and role will be exposed as OpenTofu outputs. A small step is planned to turn those outputs into the Ansible inventory, so the list of hosts is never typed twice. See Ansible for what happens next.

Drift checks

Someone resizes a disk in the hypervisor console at 2am during an incident. A scheduled tofu plan will catch that the next morning and list it in the status report, so the change is either written into code or reverted on purpose. This is part of the planned routine checks Planned.

What stays yours

• The tofu/ directory in your own Git repository
• The state, in your PostgreSQL, encrypted with a passphrase or key you hold
• Hypervisor credentials, which never leave your site

Limits and caveats

• Community providers vary in quality. The Proxmox provider is not maintained by Proxmox, and some features lag behind new Proxmox releases.
• If you lose the state encryption passphrase, the state can’t be read. Keep it with your other recovery secrets.
• The PostgreSQL that holds the state must exist before OpenTofu can use it. In stage 1 the design starts with local state and migrates it once PostgreSQL is up.
• OpenTofu doesn’t configure what runs inside the VM. That is Ansible’s job.

Last updated 25 October 2026 · Questions or corrections: sales@infratractor.com