OpenTofu uitgelegd: de Terraform-fork, de migratie en of overstappen zin heeft

Open vandaag een Terraform-module en u staat voor een vraag die drie jaar geleden nog niet bestond: is de binary die deze code uitvoert terraform, of is het tofuof moet zijn? IBM heeft de HashiCorp-overname op 27 februari 2025 afgerond voor 6,4 miljard dollar, en OpenTofu werd een CNCF Sandbox-project op 23 april 2025, en het migratiepad tussen de twee tools is nu officieel gedocumenteerd. De beslissing is niet langer hypothetisch.

Dit artikel is geschreven vanuit een infrastructuur-operations-perspectief, niet vanuit dat van een beheerd Terraform-platform. Het doel is om de werkelijke migratiekosten te scheiden van het licentie- en governance-lawaai. Dat betekent dat ik eerlijk kan zijn over wat er tijdens migratie kapotgaat, de legitieme governance-vragen, en de gevallen waarin bij Terraform blijven de juiste keuze is.

Dit artikel behandelt vier dingen: wat OpenTofu in 2026 is, de functies die Terraform niet heeft, hoe migratie er in de praktijk uitziet, en een duidelijke aanbeveling voor de meest voorkomende beslissingssituaties.

De korte versie

• OpenTofu is een open-source fork van Terraform, MPL 2.0-gelicentieerd, gehost door de Linux Foundation, en sinds 23 april 2025 een CNCF Sandbox-project. Het is afgesplitst van Terraform 1.5.x nadat HashiCorp Terraform in augustus 2023 overzette naar de Business Source License.
• Vanaf 26 juli 2026 is de huidige onderhoudsrelease v1.12.5; de GitHub-repository heeft meer dan 29.000 sterren, en de OpenTofu-projectsite vermeldt 3.900+ providers en 23.600+ modules.
• Het biedt functies die alleen OpenTofu heeft of waarin OpenTofu voorloopt en die Terraform momenteel niet op dezelfde manier evenaart: clientseitige state- en planversleuteling, provider for_each, vroege variabele-evaluatie, het enabled meta-argument, en dynamische prevent_destroy. Ephemere resources zijn niet exclusief voor OpenTofu; Terraform ondersteunt ze al sinds 1.10.
• Voor een klein Terraform-1.5.x-project met lokale of S3-state kan het eenvoudige pad een korte, omkeerbare migratie zijn. CI/CD-referenties, HCP-specifieke workflows en dependency-lock-wijzigingen zijn waar het werk toeneemt.
• Begin voor een nieuw IaC-project in 2026 met OpenTofu. Schakel bij een bestaande Terraform-implementatie over wanneer de BSL gaat knellen, wanneer u een functie nodig heeft die OpenTofu wel en Terraform niet heeft, of wanneer de door IBM gecontroleerde roadmap een echte zorg is. Anders is de kosten-batenverhouding mager.

Wat OpenTofu in 2026 is

OpenTofu is een open-source fork van Terraform, gehost door de Linux Foundation, op 23 april 2025 toegelaten tot de CNCF als Sandbox-project, en gelicentieerd onder de Mozilla Public License 2.0. De binary heet tofu. De configuratietaal is HCL, dezelfde HCL die Terraform gebruikt. Voor de meeste eenvoudige tot middelgrote projecten draait een bestaande Terraform-codebase ongewijzigd op OpenTofu.

De fork begon in augustus 2023 nadat HashiCorp Terraform van MPL 2.0 verplaatste naar de Business Source License 1.1 op 10 augustus 2023 overzette. De BSL is source-available in plaats van OSI-goedgekeurd en beperkt productiegebruik dat "concurreert met de commerciële aanbiedingen van HashiCorp". Binnen vijf dagen werd het OpenTF Manifesto gepubliceerd en een fork aangekondigd. De aankondiging van de Linux Foundation introduceerde OpenTofu formeel op 20 september 2023.

De aankondiging van de Linux Foundation noemde Harness, Gruntwork, Spacelift, env0, Scalr, Digger, Terrateam, Massdriver en Terramate als oprichtende ondersteuners, met minstens 18 engineers die zich voor minstens vijf jaar fulltime toewijdden. OpenTofu is afgesplitst van Terraform 1.5.x, de laatste MPL 2.0-lijn.

Waar het project vandaag staat: v1.12.5 is de huidige onderhoudsrelease, en de officiële site vermeldt 3.900+ providers en 23.600+ modules. Adoptiesignalen blijven niet langer beperkt tot het momentum van een protest-fork: Fidelity-migratiecasestudy beschrijft een programma dat meer dan 50.000 state-bestanden en vier miljoen resources omvat.

De relevante zakelijke context: IBM rondde de overname van HashiCorp af op 27 februari 2025, voor 6,4 miljard dollar. De roadmap van Terraform wordt nu bepaald binnen een veel grotere enterprise-leverancier. Dat is niet automatisch goed of slecht voor gebruikers, maar het maakt deel uit van de afweging die teams in 2026 maken.

Waar OpenTofu verschilt van Terraform

Sinds de fork hebben de twee projecten verschillende functiepaden gevolgd. De onderstaande tabel is de korte versie; de toelichting daarna legt uit wat elk verschil concreet betekent voor de praktijk.

Clientseitige state-versleuteling (v1.7.0, 30 april 2024). OpenTofu kan state- en planbestanden versleutelen binnen de tool zelf met PBKDF2, AWS KMS, GCP KMS of OpenBao. Terraform delegeert versleuteling in rust doorgaans aan het gekozen backend, terwijl lokale state platte tekst blijft. De clientseitige versleuteling van OpenTofu kan een gestolen state-object of gecachte plan beschermen, mits de decryptiesleutel er niet mee wordt blootgesteld. Het vervangt geen TLS, backend-toegangscontroles of discipline in geheimenbeheer.

De configuratie ziet er ongeveer zo uit:

terraform {
  encryption {
    key_provider "pbkdf2" "passphrase" {
      passphrase = var.tofu_state_passphrase
    }
    method "aes_gcm" "default" {
      keys = key_provider.pbkdf2.passphrase
    }
    state {
      method = method.aes_gcm.default
    }
  }
}

Leverancier for_each (v1.9). U kunt providerconfiguraties itereren zoals u resources itereert. Bij multi-region- of multi-account-opzetten elimineert dit een langlopende klasse workarounds. U hoeft niet langer handmatig één gealiaste provider per regio te bouwen; u kunt één blok aansturen vanuit een map.

Vroege variabele-evaluatie (v1.8). Variabelen kunnen worden gerefereerd op plekken die eerder beperkt waren, waaronder backend- en module-source-argumenten. Dit is nuttig wanneer één root-module meerdere omgevingen aanstuurt die slechts in een kleine set variabelen verschillen.

Ephemere resources en het enabled meta-argument (v1.11.0, 9 december 2025). OpenTofu 1.11 voegde ephemere resources en het enabled meta-argument toegevoegd. Ephemere resources bestaan alleen binnen één plan/apply-cyclus en blijven niet bewaard in de state, wat nuttig is voor kortlevende credentials. Ze zijn niet exclusief voor OpenTofu: Terraform introduceerde ze in 1.10 en voegde write-only-argumenten toe in 1.11. De OpenTofu-specifieke functie hier is enabled, waarmee je een resourceblok via een expressie aan- of uitzet zonder de gymnastiek van conditionele count count

Dynamisch prevent_destroy (v1.12). Terraforms prevent_destroy -instelling accepteert alleen letterlijke waarden. OpenTofu 1.12 laat u die berekenen, zodat één module staging verwijderbaar kan houden terwijl productie beschermd blijft.

De licentieregel is het structurele verschil dat niet als functie zichtbaar wordt. MPL 2.0 is OSI-goedgekeurd en copyleft op bestandsniveau. Terraforms BSL-1.1-licentie is source-available, bevat een extra gebruiksbeperking, en verandert vier jaar na publicatie van elk gelicentieerd werk naar MPL 2.0. Voor de meeste teams is het praktische effect klein; voor leveranciers die iets bouwen dat dicht bij HashiCorps commerciële aanbod komt, is dat precies de reden dat de fork bestaat.

Migratie: Wat er werkelijk stukgaat

De officiële migratiehandleiding is bewust kort en omkeerbaar: back-up van state en code, OpenTofu installeren, voer tofu init, vergelijk tofu plan en test een kleine wijziging. De lastige onderdelen zijn niet de commando's. Het zijn de omliggende CI/CD-referenties, HCP-specifieke workflows, dependency-lock-wijzigingen, en de organisatorische toetsing die gepaard gaat met het overnemen van een fork.

Het eenvoudige pad

Voor een project dat geen HCP Terraform gebruikt en geen duizend pipeline-referenties naar terraform heeft, is de migratie eenvoudig.

# Back up state first, non-negotiable.
cp terraform.tfstate terraform.tfstate.bak

# Install OpenTofu (Linux example).
curl --proto '=https' --tlsv1.2 -fsSL \
  https://get.opentofu.org/install-opentofu.sh | sh -s -- --install-method standalone

# Re-initialize against the OpenTofu registry.
tofu init -upgrade

# Verify parity with what Terraform was doing.
tofu plan

tofu plan zou moeten overeenkomen met het plan dat Terraform produceerde. Bij een onverwacht verschil controleert u providerversies, backend-instellingen en eventuele Terraform-functies na 1.5.x voordat u toepast.

Twee nuances zijn belangrijk voordat u iets uitvoert. Ten eerste is OpenTofu voor de in deze gids beschreven gevallen grotendeels configuratiecompatibel met Terraform-stijl HCL, maar functies die na Terraform 1.5.x zijn toegevoegd, vereisen nog steeds een compatibiliteitscontrole. Ten tweede tofu init -upgrade kan .terraform.lock.hcl bijwerken, inclusief provider-bronadressen en checksum-vermeldingen. Beoordeel die metadata los van infrastructuurdrift.

De echte obstakels

Drie dingen kunnen een snelle CLI-migratie veranderen in een breder platformproject. Geen daarvan is een bug.

HCP Terraform-workspaces. OpenTofu bevat cloud- en remote-integraties voor compatibele remote-diensten, waaronder HCP Terraform in scenario's met lokale uitvoering en state-opslag. Het lastigere deel is HCP-specifieke remote-uitvoering en platformfuncties: Sentinel, run triggers, dynamische credentials, Stacks, en elk dienstgedrag dat OpenTofu niet volledig kan testen of ondersteunen. Als die centraal staan, test eerst met één workspace; als u HCP verlaat, migreer de state en herbouw die platformcontroles.

Pro-tip: Het verlaten van HCP Terraform kan de grootste verborgen kostenpost zijn als het bestand leunt op HCP-specifieke workflows. Voer, voordat u beslist, terraform state pull > state.json en bekijk de grootte en het aantal resources. Eén workspace met 200 resources is een heel ander project dan een vloot van 50 workspaces met run triggers en policy sets. Dat laatste is een platform-engineeringmigratie, geen tool-wissel.

CI/CD-pipelines die hardcoded zijn voor terraform. Elke verwijzing naar terraform plan, terraform apply, het binary-pad, de Docker-image, en de GitHub Actions- of GitLab CI-stap moet worden herzien. Voor GitHub Actions ziet de wissel er ongeveer zo uit:

# Before
- name: Setup Terraform
  uses: hashicorp/setup-terraform@v3
  with:
    terraform_version: 1.5.7

- run: terraform init
- run: terraform plan

# After
- name: Setup OpenTofu
  uses: opentofu/setup-opentofu@v2
  with:
    tofu_version: 1.12.5

- run: tofu init
- run: tofu plan

Dat is het triviale geval: één workflow, één repo. In een monorepo met gedeelde composite actions, meerdere pipelines en een herbruikbare workflow-bibliotheek is het reviewoppervlak groter. Het werk is mechanisch, maar kan langer duren dan de CLI-wissel.

Beoordeling van het dependency-lock-bestand. tofu init kan .terraform.lock.hcl bijwerken, inclusief provider-bronadressen en checksum-vermeldingen. OpenTofu 1.12 kan ook complete h1: checksum-sets toevoegen. Behandel de diff als dependency-metadata om apart te beoordelen en te committen, niet als infrastructuurdrift.

Pro-tip: De diff van het lock-bestand kan er bij de eerste commit rommelig uitzien. Voer tofu init -upgrade op een schone branch, commit alleen het lock-bestand met een duidelijk bericht zoals "review OpenTofu lock-file changes", en rebase het feature-werk daarna erbovenop. Het mengen van dependency-metadata met een feature-PR maakt beide wijzigingen lastiger te beoordelen.

Weerstand van stakeholders. "We draaien nu een fork" landt in elke organisatie anders. Het eerlijke tegenargument is dat OpenTofu voor de in deze gids beschreven gevallen grotendeels configuratiecompatibel blijft met Terraform-stijl HCL, dus de wissel is meestal omkeerbaar. Als OpenTofu morgen zou verdwijnen, konden veel teams Terraform herinstalleren, het lock-bestand beoordelen, en dezelfde .tf .tf-bestanden blijven gebruiken. Valideer eerst post-fork-functies; die kanttekening is geloofwaardiger dan het beloven van perfecte uitwisselbaarheid.

Wanneer migratie echt lastig is

Dat eenvoudige pad geldt niet voor elk Terraform-bestand.

Migratie wordt aanzienlijk lastiger wanneer:

• de state groot is (duizenden resources, tientallen workspaces) en zich in HCP Terraform bevindt.
• de codebase diep HCP-exclusieve functies gebruikt: Sentinel-policies verweven in workspaces, run triggers, door HCP beheerde dynamische providercredentials. Terraform Stacks is HCP-exclusief en heeft geen OpenTofu-equivalent, dat valt hier buiten bereik.
• een enterprise-audit of compliance-framework "Terraform" met naam noemt als het officiële IaC-tool, wat bovenop het technische probleem een inkoop- en documentatieprobleem oplevert.
• een grote modulebibliotheek interne versiebeperkingen heeft die werden opgelost op basis van Terraform-specifiek registry-gedrag.

Niet elk team hoeft te migreren. De kosten-batenafweging is alleen zinvol wanneer de BSL-beperkingen uw use case daadwerkelijk raken, wanneer een specifieke OpenTofu-functie iets concreets ontgrendelt, of wanneer de door IBM gecontroleerde roadmap een echte zorg is voor uw organisatie. Als niets daarvan geldt, is bij Terraform blijven een volstrekt verdedigbare keuze.

Moet u overstappen?

Er is hier geen enkel juist antwoord. Als ik de beslisboom voor een team teken, komen vier veelvoorkomende situaties naar boven, en de juiste zet hangt af van in welke u zich bevindt.

Nieuwe IaC-adoptie (greenfield). Begin met OpenTofu. De licentie is MPL 2.0, de governance ligt bij de Linux Foundation en de CNCF, en het project heeft een actief releaseritme. De onderscheidende kenmerken zijn onder meer clientseitige state-versleuteling, provider for_each, enabled, en dynamische prevent_destroy. Er is geen BSL-frictie om rekening mee te houden. Dit is de sterkste aanbeveling in dit artikel.

Bestaande Terraform-gebruiker, klein tot middelgroot project. Schakel over als een van deze drie triggers zich voordoet. Eén: u verkoopt of zou een product kunnen verkopen dat de BSL-uitzondering "concurreert met HashiCorp" raakt; de juridische afweging is duidelijker bij MPL 2.0. Twee: u heeft clientseitige state-versleuteling nodig, provider for_each, enabled, of dynamische prevent_destroy en de Terraform-workaround is niet langer de moeite van het onderhouden waard. Drie: u geeft de voorkeur aan governance door meerdere partijen boven een roadmap van één leverancier. Als niets daarvan geldt en Terraform draait probleemloos, blijf dan. Migratie is in veel bestanden omkeerbaar, maar niet gratis.

Intensieve HCP Terraform-gebruiker. Behandel dit als een platformbeslissing, niet automatisch als een backendmigratie. OpenTofu kan compatibele remote-backends gebruiken, maar HCP-specifieke remote-uitvoering, Sentinel, run triggers, dynamische credentials en Stacks vereisen nog steeds een functie-voor-functie-beoordeling. Als die controles centraal staan, test eerst. Verlaat u HCP om licentie-, kosten- of governance-redenen, plan het werk dan als een platformmigratie.

Pulumi of een ander niet-HCL-alternatief overwegen. OpenTofu is de dichtstbijzijnde route als u HCL en de meeste bestaande workflows wilt behouden. Pulumi is een bredere platform- en taalkeuze: TypeScript, Python, Go of .NET die cloud-API's aansturen. De overstap daarheen kan conversie of een herschrijving vergen, dus evalueer dat los van een simpele Terraform-naar-OpenTofu-binarywissel.

Nog iets dat direct de moeite waard is om te behandelen: de legitieme kritiek dat OpenTofu deels een SaaS-leveranciersafdekking is. Een Hacker News-topic over de BSL-wijziging bracht de zorg naar boven dat de oprichtende leden van het project commerciële Terraform-platforms zijn met hun eigen licentieflexibiliteitsmotief. Ik neem die zorg serieus. De verzachting is de governance-structuur, hosting door de Linux Foundation, CNCF Sandbox-status, MPL 2.0 op elk bestand, wat een toekomstige herlicentiëring aanzienlijk lastiger maakt dan bij één leverancier het geval was. Onmogelijk maakt het het niet. Wel kostbaar genoeg om een echte rem te zijn.

Snel oordeel. Begin voor nieuw IaC-werk in 2026 met OpenTofu. De licentie, governance, actieve ontwikkeling en functieset maken het een sterke standaardkeuze. Schakel bij bestaande Terraform-implementaties over wanneer een van de drie bovenstaande triggers geldt; anders is de kosten-batenafweging mager en is blijven prima.

Zodra de toolkeuze duidelijk is, is de volgende praktische vraag waar OpenTofu moet draaien. Die beslissing beïnvloedt de omgang met secrets, kosten, herhaalbaarheid, en hoeveel controle uw team heeft over de uitvoeringsomgeving.

OpenTofu zelf draaien

OpenTofu is een CLI-binary. Waar u het uitvoert, bepaalt veel over kosten, beveiliging en wat u ermee kunt doen. Er zijn grofweg drie zinvolle plekken om het neer te zetten.

Laptop of ontwikkelmachine. Prima voor eenmalige plannen, prototyping en kleine persoonlijke projecten. Het is een slechte standaard voor gedeelde productie-workflows, tenzij remote state, locking en reviewdiscipline al zijn afgedwongen. Teams profiteren meestal van een canonieke uitvoeringsomgeving in plaats van welke laptop dan ook die laatst tofu apply.

Beheerde CI-runner (GitHub Actions, GitLab CI, enz.). Het gangbare pad. De opentofu/setup-opentofu -action is een drop-in vervanging voor hashicorp/setup-terraform. Dit werkt goed voor de meeste teams en projecten. Afwegingen: secrets gaan via een externe CI-dienst, gratis minuten kunnen opraken bij grote state-operaties, en de runner-omgeving is vluchtig, wat meestal een voordeel is maar soms een beperking. Zie GitHub vs GitLab als u nog kiest tussen gehoste CI-opties, en Best CI/CD Tools voor het bredere landschap.

Zelf gehoste runner op een VPS. Nuttig wanneer de afwegingen van beheerde CI niet meer werken: secrets moeten van een externe dienst wegblijven, CI-minuten worden duur, of u wilt persistente providercaches. De opzet is eenvoudig: een Linux-VPS, de OpenTofu-binary, een GitHub Actions- of GitLab Runner-agent, en Docker voor job-isolatie. Zie Install Docker on VPS als dat onderdeel nieuw voor u is. Voor een runner van een klein team is 4 GB RAM, 2 vCPU en 60 GB NVMe een redelijk startpunt; schaal CPU, geheugen en opslag voor grotere plannen en hogere concurrency.

Voor teams die strakkere controle over runner-secrets, persistente providercaches, of voorspelbare CI-kosten nodig hebben, kan een zelf gehoste runner op een VPS zinvol zijn. Geef in die opzet prioriteit aan root-toegang, snelle NVMe-opslag, eenvoudig herschalen, en genoeg CPU/RAM voor grotere planoperaties.

Cloudzy Linux VPS -instanties passen bij dat patroon van een zelf gehoste runner met root-toegang, NVMe-opslag en flexibele dimensionering, zodat u klein kunt beginnen en de runner kunt opschalen naarmate uw OpenTofu-workloads groeien.

Veelgestelde vragen

Is OpenTofu hetzelfde als Terraform?

Niet helemaal. OpenTofu begon als een fork van Terraform 1.5.x en blijft grotendeels configuratiecompatibel met Terraform-stijl HCL: dezelfde .tf .tf-bestanden, dezelfde providers, en dezelfde plan/apply plan/apply-workflow voor veel projecten. Ze verschillen in licentie en in functies die na de fork zijn toegevoegd. OpenTofu heeft clientseitige state-versleuteling, provider for_each, enabled, en dynamische prevent_destroy; Terraform heeft zijn eigen post-fork-functies, waaronder ephemere resources.

Ondersteunt OpenTofu al mijn Terraform-providers?

Voor grote providers zoals AWS, GCP, Azure, Kubernetes en Helm, over het algemeen ja. De OpenTofu Registry meldt 3.900+ providers vanaf juli 2026. tofu init kan .terraform.lock.hcl -metadata bijwerken. Controleer voor niche-, leveranciersspecifieke of nieuw gepubliceerde providers rechtstreeks de beschikbaarheid en versieondersteuning voordat u overstapt.

Kan OpenTofu zelf ooit opnieuw gelicentieerd worden?

Een toekomstige herlicentiëring is lastiger dan bij Terraform, maar niet onmogelijk. OpenTofu is MPL 2.0, gehost door de Linux Foundation, en sinds 23 april 2025 een CNCF Sandbox-project. De governance is multi-party en de licentie is OSI-goedgekeurd. Een eenzijdige herlicentiëring door één enkele oprichter zou in strijd zijn met zowel het charter van de stichting als met de bestaande MPL-2.0-bijdragen, die zouden moeten worden verwijderd of herschreven. De zorg is legitiem; de structurele barrières zijn reëel.

Wat betekent de IBM-overname van HashiCorp voor de toekomst van Terraform?

IBM rondde de overname van HashiCorp af op 27 februari 2025, voor 6,4 miljard dollar. De roadmap van Terraform ligt nu binnen een grotere enterprise-leverancier. De overname alleen bewijst niets over toekomstige licentiëring of productrichting; beoordeel actuele release notes, licentierichtlijnen en HCP-productwijzigingen in plaats van eigendom als voorspelling te behandelen.

Is OpenTofu productieklaar in 2026?

Ja. v1.12.5 is de huidige onderhoudsrelease, het project zit in de CNCF Sandbox, en Fidelity heeft productie-adoptie beschreven over een IaC-bestand met meer dan 50.000 state-bestanden en vier miljoen resources. Productieklaar betekent niet functie-identiek: teams die afhankelijk zijn van HCP-exclusieve mogelijkheden zoals Terraform Stacks hebben nog steeds een aparte compatibiliteitsbeslissing nodig.