OpenTofu Forklaret: Forken, Migreringen og Om Du Bør Skifte

Åbn et Terraform-modul i dag, og du står over for et spørgsmål, der ikke fandtes for tre år siden: er den binære fil, der kører denne kode, terraform, eller er det tofu? IBM afsluttede sin HashiCorp-opkøb den 27. februar 2025 for 6,4 milliarder dollar, og OpenTofu blev et CNCF Sandbox-projekt den 23. april 2025, og migreringsvejen mellem de to værktøjer er nu officielt dokumenteret. Beslutningen er ikke længere hypotetisk.

Denne artikel er skrevet ud fra et infrastruktur-drift-perspektiv, ikke ud fra perspektivet hos en administreret Terraform-platform. Målet er at adskille de reelle migreringsomkostninger fra støjen omkring licens og governance. Det betyder, at jeg kan være ærlig om, hvad der går i stykker under migreringen, de legitime governance-spørgsmål, og de tilfælde, hvor det er det rigtige valg at blive på Terraform.

Denne artikel dækker fire ting: hvad OpenTofu er i 2026, de funktioner Terraform ikke har, hvordan migreringen ser ud i praksis, og en klar anbefaling til de almindelige beslutningsscenarier.

Den korte version

• OpenTofu er en open source-fork af Terraform, licenseret under MPL 2.0, hostet af Linux Foundation, og et CNCF Sandbox-projekt siden 23. april 2025. Den blev forket fra Terraform 1.5.x, efter at HashiCorp flyttede Terraform til Business Source License i august 2023.
• Pr. 26. juli 2026 er den aktuelle vedligeholdelsesudgivelse v1.12.5; GitHub-repositoriet har mere end 29.000 stjerner, og OpenTofu-projektsiden opgiver 3.900+ providere og 23.600+ moduler.
• Den leverer funktioner, der er unikke for OpenTofu, eller hvor OpenTofu er førende, og som Terraform i øjeblikket ikke matcher på samme måde: klientside-kryptering af state og plan, provider for_each, tidlig variabel-evaluering, enabled meta-argumentet, og dynamisk prevent_destroy. Ephemeral resources er ikke unikke for OpenTofu; Terraform har understøttet dem siden 1.10.
• For et lille Terraform 1.5.x-projekt med lokal eller S3-state kan den ideelle vej være en kort, reversibel migrering. CI/CD-referencer, HCP-specifikke workflows og ændringer i dependency-lock er der, hvor arbejdet vokser.
• For et nyt IaC-projekt i 2026, start med OpenTofu. For en eksisterende Terraform-installation, skift når BSL bider, når du har brug for en funktion, OpenTofu har og Terraform ikke har, eller når en IBM-ejet roadmap er en reel bekymring. Ellers er cost-benefit tyndt.

Hvad OpenTofu er i 2026

OpenTofu er en open source-fork af Terraform, hostet af Linux Foundation, optaget i CNCF som et Sandbox-projekt den 23. april 2025, og licenseret under Mozilla Public License 2.0. Den binære fil er tofu. Konfigurationssproget er HCL, det samme HCL som Terraform bruger. For de fleste simple til mellemstore projekter kører en eksisterende Terraform-kodebase uændret på OpenTofu.

Forken startede i august 2023, efter at HashiCorp flyttede Terraform fra MPL 2.0 til Business Source License 1.1 den 10. august 2023 påbegyndte. BSL er source-available snarere end OSI-godkendt og begrænser produktionsbrug, der "konkurrerer med HashiCorps kommercielle tilbud." Inden for fem dage blev OpenTF Manifesto udgivet, og en fork blev annonceret. Linux Foundations meddelelse introducerede formelt OpenTofu den 20. september 2023.

Linux Foundations meddelelse nævnte Harness, Gruntwork, Spacelift, env0, Scalr, Digger, Terrateam, Massdriver og Terramate blandt de grundlæggende støtter, med mindst 18 ingeniører forpligtet fuldtid i minimum fem år. OpenTofu blev forket fra Terraform 1.5.x, den sidste MPL 2.0-linje.

Hvor projektet står i dag: v1.12.5 er den aktuelle vedligeholdelsesudgivelse, og den officielle side opgiver 3.900+ providere og 23.600+ moduler. Adoptionssignalerne er ikke længere begrænset til momentum fra en protest-fork: Fidelity-migreringscasestudie beskriver et program, der spænder over mere end 50.000 state-filer og fire millioner ressourcer.

Den relevante forretningsmæssige kontekst: IBM afsluttede sit opkøb af HashiCorp den 27. februar 2025 for 6,4 milliarder dollar. Terraforms roadmap ligger nu inde i en langt større enterprise-leverandør. Det er ikke automatisk godt eller dårligt for brugerne, men det indgår i den vurdering, teams foretager i 2026.

Hvor OpenTofu adskiller sig fra Terraform

Siden forken har de to projekter taget forskellige funktionsveje. Tabellen nedenfor er den korte version; noterne, der følger, forklarer, hvad hver forskel betyder for praktikere.

Klientside state-kryptering (v1.7.0, 30. april 2024). OpenTofu kan kryptere state- og plan-filer internt i værktøjet med PBKDF2, AWS KMS, GCP KMS eller OpenBao. Terraform overlader generelt kryptering ved hvile til den valgte backend, mens lokal state forbliver i klartekst. OpenTofus klientside-kryptering kan beskytte et stjålet state-objekt eller en cachet plan, forudsat at dekrypteringsnøglen ikke er eksponeret sammen med det. Det erstatter ikke TLS, backend-adgangskontroller eller disciplin omkring secret-management.

Konfigurationen ser nogenlunde sådan ud:

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
    }
  }
}

Leverandør for_each (v1.9). Du kan iterere provider-konfigurationer på samme måde, som du itererer ressourcer. Til multi-region- eller multi-account-opsætninger fjerner dette en langvarig klasse af workarounds. Du behøver ikke længere at håndrulle én aliaset provider pr. region; du kan styre det hele fra én blok ud fra et map.

Tidlig variabel-evaluering (v1.8). Variabler kan nu refereres steder, der tidligere var begrænsede, herunder backend- og module-source-argumenter. Dette er nyttigt, når ét root-modul driver flere miljøer, der kun adskiller sig ved et lille sæt variabler.

Ephemeral resources og enabled meta-argumentet (v1.11.0, 9. december 2025). OpenTofu 1.11 tilføjede ephemeral resources og enabled meta-argumentet. Ephemeral resources findes kun inden for en enkelt plan/apply-cyklus og gemmes ikke i state, hvilket er nyttigt til kortlivede credentials. De er ikke unikke for OpenTofu: Terraform introducerede dem i 1.10 og tilføjede write-only-argumenter i 1.11. Den OpenTofu-specifikke funktion her er enabled, som slår en resource-blok til/fra ud fra et udtryk uden brug for betinget count gymnastik.

Dynamisk prevent_destroy (v1.12). Terraforms prevent_destroy -indstilling accepterer kun literale værdier. OpenTofu 1.12 lader dig beregne den, så ét modul kan holde staging destroybar, mens produktion beskyttes.

Licensrækken er den strukturelle forskel, der ikke viser sig som en funktion. MPL 2.0 er OSI-godkendt og fil-niveau copyleft. Terraforms BSL 1.1-licens er source-available, indeholder en yderligere brugsbegrænsning, og skifter til MPL 2.0 fire år efter, at hvert licenseret værk er udgivet. For de fleste teams er den praktiske effekt lille; for leverandører, der bygger noget tæt på HashiCorps kommercielle tilbud, er det grunden til, at forken eksisterer.

Migrering: Hvad der rent faktisk går i stykker

Den officielle migreringsguide er bevidst kort og reversibel: tag backup af state og kode, installer OpenTofu, kør tofu init, sammenlign tofu plan, og test en lille ændring. De svære dele er ikke kommandoerne. Det er de omkringliggende CI/CD-referencer, HCP-specifikke workflows, dependency-lock-ændringer og den organisatoriske gennemgang, der følger med at tage en fork i brug.

Den Nemme Vej

For et projekt, der ikke bruger HCP Terraform og ikke har tusindvis af pipeline-referencer til terraform, er migreringen ligetil.

# 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 bør matche den plan, Terraform producerede. Hvis der er en uventet diff, så tjek provider-versioner, backend-indstillinger og eventuelle Terraform-funktioner efter 1.5.x, før du anvender den.

To nuancer betyder noget, før du kører noget som helst. For det første er OpenTofu bredt konfigurationskompatibel med Terraform-stil HCL for de tilfælde, denne guide beskriver, men funktioner tilføjet efter Terraform 1.5.x kræver stadig et kompatibilitetstjek. For det andet, tofu init -upgrade kan opdatere .terraform.lock.hcl, herunder provider source-adresser og checksum-poster. Gennemgå disse metadata separat fra infrastructure drift.

De Reelle Forhindringer

Tre ting kan gøre en hurtig CLI-migrering til et bredere platformsprojekt. Ingen af dem er fejl.

HCP Terraform-workspaces. OpenTofu inkluderer cloud- og remote-integrationer til kompatible remote-tjenester, herunder HCP Terraform i lokale eksekverings- og state-lagringsscenarier. Den sværere del er HCP-specifik remote-eksekvering og platformsfunktioner: Sentinel, run triggers, dynamiske credentials, Stacks, og enhver tjenesteadfærd, OpenTofu ikke fuldt ud kan teste eller understøtte. Hvis disse er centrale, så pilottest ét workspace først; hvis du forlader HCP, migrer state og genskab disse platformskontroller.

Pro-tip: At forlade HCP Terraform kan være den største skjulte omkostning, når infrastrukturen er afhængig af HCP-specifikke workflows. Før du beslutter dig, så kør terraform state pull > state.json og undersøg størrelsen og antallet af ressourcer. Ét workspace med 200 ressourcer er et andet projekt end en flåde på 50 workspaces med run triggers og policy sets. Det sidste er en platform-engineering-migrering, ikke en simpel værktøjsudskiftning.

CI/CD-pipelines hårdkodet til terraform. Enhver reference til terraform plan, terraform apply, den binære sti, Docker-imaget og GitHub Actions- eller GitLab CI-trinnet skal gennemgås. For GitHub Actions ser udskiftningen nogenlunde sådan ud:

# 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

Det er det trivielle tilfælde: én workflow, ét repo. I en monorepo med delte composite actions, flere pipelines og et genbrugeligt workflow-bibliotek er gennemgangsfladen bredere. Arbejdet er mekanisk, men det kan tage længere tid end selve CLI-udskiftningen.

Gennemgang af dependency lock-filen. tofu init kan opdatere .terraform.lock.hcl, herunder provider source-adresser og checksum-poster. OpenTofu 1.12 kan også tilføje komplette h1: checksum-sæt. Betragt diff'en som dependency-metadata, der skal gennemgås og committes separat, ikke som infrastructure drift.

Pro-tip: Lock-filens diff kan se støjende ud ved det første commit. Kør tofu init -upgrade på en ren branch, commit kun lock-filen med en klar besked som "review OpenTofu lock-file changes", og rebase derefter feature-arbejdet oven på den. At blande afhængighedsmetadata ind i en feature-PR gør begge ændringer sværere at gennemgå.

Modstand fra stakeholders. "Vi kører nu en fork" lander forskelligt i forskellige organisationer. Det ærlige modargument er, at OpenTofu forbliver bredt konfigurationskompatibel med Terraform-stil HCL for de tilfælde, denne guide beskriver, så udskiftningen er som regel reversibel. Hvis OpenTofu forsvandt i morgen, kunne mange teams geninstallere Terraform, gennemgå lock-filen og fortsætte med at bruge de samme .tf filer. Valider post-fork-funktioner først; det forbehold er mere troværdigt end at love perfekt indbyrdes udskiftelighed.

Når Migrering Er Reelt Svær

Den nemme vej gælder ikke for enhver Terraform-infrastruktur.

Migreringen bliver markant sværere, når:

• State er stor (tusindvis af ressourcer, snesevis af workspaces) og ligger i HCP Terraform.
• Kodebasen bruger HCP-eksklusive funktioner dybt: Sentinel-politikker koblet ind i workspaces, run triggers, HCP-administrerede dynamiske provider-credentials. Terraform Stacks er HCP-eksklusivt og har ingen OpenTofu-pendant, hvilket er uden for denne artikels omfang.
• Et enterprise-audit eller compliance-framework navngiver "Terraform" som det officielle IaC-værktøj, hvilket er et indkøbs- og dokumentationsproblem oveni det tekniske.
• Et stort modulbibliotek har interne versionsbegrænsninger, der blev resolvet mod Terraform-specifik registry-adfærd.

Ikke alle teams bør migrere. Cost-benefit giver kun mening, når BSL-begrænsningerne rent faktisk påvirker din use case, når en specifik OpenTofu-funktion løser noget konkret, eller når en IBM-styret roadmap er en reel bekymring for din organisation. Hvis intet af dette gælder, er det at blive på Terraform et helt forsvarligt valg.

Bør du skifte?

Der er ikke ét rigtigt svar her. Når jeg tegner beslutningstræet for et team, dukker fire almindelige mønstre op, og det rigtige træk afhænger af, hvilket mønster man er i.

Ny IaC-adoption (greenfield). Start med OpenTofu. Licensen er MPL 2.0, governance ligger hos Linux Foundation og CNCF, og projektet har en aktiv udgivelseskadence. Dets differentiatorer inkluderer klientside-kryptering af state, provider for_each, enabledog dynamisk prevent_destroy. Der er ingen BSL-friktion at planlægge omkring. Dette er den stærkeste anbefaling i denne artikel.

Eksisterende Terraform-bruger, lille til mellemstort projekt. Skift, hvis en af tre triggere udløses. Én: du sælger eller kunne komme til at sælge et produkt, der kunne støde imod BSL'ens "konkurrerer med HashiCorp"-undtagelse; den juridiske kalkule er renere med MPL 2.0. To: du har brug for klientside-kryptering af state, provider for_each, enabledeller dynamisk prevent_destroy på, og Terraform-workarounden ikke længere er værd at vedligeholde. Tre: du foretrækker multi-part governance frem for en enkelt-leverandør-roadmap. Hvis intet af dette gælder, og Terraform kører problemfrit, så bliv. Migrering er reversibel i mange infrastrukturer, men ikke gratis.

Tung HCP Terraform-bruger. Betragt dette som en platformsbeslutning, ikke automatisk som en backend-migrering. OpenTofu kan bruge kompatible remote-backends, men HCP-specifik remote-eksekvering, Sentinel, run triggers, dynamiske credentials og Stacks kræver stadig en funktion-for-funktion-vurdering. Hvis disse kontroller er centrale, så pilottest først. Hvis du forlader HCP af licens-, omkostnings- eller governance-årsager, så planlæg arbejdet som en platformsmigrering.

Overvejer Pulumi eller et andet ikke-HCL-alternativ. OpenTofu er den nærmeste vej, hvis du vil beholde HCL og de fleste eksisterende workflows. Pulumi er et bredere platforms- og sprogvalg: TypeScript, Python, Go eller .NET, der styrer cloud-API'er. At flytte dertil kan indebære konvertering eller en omskrivning, så evaluer det separat fra en simpel Terraform-til-OpenTofu-binærændring.

Én ting mere er værd at adressere direkte: den legitime kritik af, at OpenTofu delvist er en SaaS-leverandørs afdækning. En Hacker News-tråd om BSL-ændringen bragte bekymringen frem om, at projektets grundlæggende medlemmer er kommercielle Terraform-platforme med deres eget motiv om licens-fleksibilitet. Jeg tager den bekymring alvorligt. Afhjælpningen er governance-strukturen, Linux Foundation-hostingen, CNCF Sandbox, MPL 2.0 på hver fil, hvilket gør en fremtidig relicensiering betydeligt sværere, end en enkelt-leverandør-relicensiering var. Det gør det ikke umuligt. Det gør det dyrt nok til, at det er en reel kontrolmekanisme.

Kort konklusion. For nyt IaC-arbejde i 2026, start med OpenTofu. Dets licens, governance, aktive udvikling og funktionssæt gør det til et stærkt standardvalg. For eksisterende Terraform-installationer, skift når en af de tre triggere ovenfor gælder; ellers er cost-benefit tyndt, og det er fint at blive.

Når værktøjsvalget står klart, er det næste praktiske spørgsmål, hvor OpenTofu skal køre. Den beslutning påvirker håndtering af secrets, omkostninger, reproducerbarhed og hvor meget kontrol dit team har over eksekveringsmiljøet.

At Køre OpenTofu Selv

OpenTofu er en CLI-binær fil. Hvor du kører den, afgør meget om omkostninger, sikkerhed og hvad du kan gøre med den. Der er groft sagt tre fornuftige steder at placere den.

Bærbar eller udviklingsmaskine. Fint til enkeltstående plans, prototyping og små personlige projekter. Det er et dårligt standardvalg til delte produktions-workflows, medmindre remote state, locking og review-disciplin allerede håndhæves. Teams har som regel gavn af et kanonisk eksekveringsmiljø frem for hvilken som helst bærbar, der sidst kørte tofu apply.

Administreret CI-runner (GitHub Actions, GitLab CI osv.). Den gængse vej. opentofu/setup-opentofu -actionen er en drop-in-erstatning for hashicorp/setup-terraform. Dette fungerer godt for de fleste teams og projekter. Kompromiser: secrets passerer gennem en tredjeparts CI-tjeneste, gratis minutter kan løbe tør ved store state-operationer, og runner-miljøet er ephemeral, hvilket normalt er en fordel, men nogle gange en begrænsning. Se GitHub vs GitLab hvis du stadig er ved at vælge mellem hostede CI-muligheder, og Best CI/CD Tools for det bredere landskab.

Selv-hostet runner på en VPS. Nyttigt, når kompromiserne ved administreret CI ikke længere holder: secrets skal holdes væk fra en tredjepartstjeneste, CI-minutter bliver dyre, eller du ønsker persistente provider-caches. Opsætningen er ligetil: en Linux VPS, OpenTofu-binæren, en GitHub Actions- eller GitLab Runner-agent, og Docker til job-isolation. Se Install Docker on VPS hvis den del er ny for dig. Til en runner for et lille team er 4 GB RAM, 2 vCPU og 60 GB NVMe et fornuftigt udgangspunkt; skaler CPU, hukommelse og lagerplads til større plans og højere samtidighed.

For teams, der har brug for strammere kontrol over runner-secrets, persistente provider-caches eller forudsigelige CI-omkostninger, kan en selv-hostet runner på en VPS give mening. I den opsætning bør du prioritere root-adgang, hurtig NVMe-lagring, nem størrelsesændring og nok CPU/RAM til større plan-operationer.

Cloudzy Linux VPS -instanser passer til dette selv-hostet-runner-mønster med root-adgang, NVMe-lagring og fleksibel størrelse, så du kan starte i det små og skalere runneren, efterhånden som dine OpenTofu-workloads vokser.

Ofte stillede spørgsmål

Er OpenTofu det Samme som Terraform?

Ikke helt. OpenTofu startede som en fork af Terraform 1.5.x og forbliver bredt konfigurationskompatibel med Terraform-stil HCL: de samme .tf filer, providere og plan/apply workflow for mange projekter. De adskiller sig i licens og i funktioner tilføjet efter forken. OpenTofu har klientside-kryptering af state, provider for_each, enabledog dynamisk prevent_destroy; Terraform har sine egne post-fork-funktioner, herunder ephemeral resources.

Vil OpenTofu Understøtte Alle Mine Terraform-Providere?

For større providere som AWS, GCP, Azure, Kubernetes og Helm, ja generelt. Den OpenTofu Registry opgiver 3.900+ providere pr. juli 2026. tofu init kan opdatere .terraform.lock.hcl -metadata. For nicheprovidere, leverandørspecifikke eller nyligt udgivne providere, bør du verificere tilgængelighed og versionsunderstøttelse direkte, før du skifter.

Kunne OpenTofu Selv Blive Relicenseret En Dag?

En fremtidig relicensiering er sværere, end den var for Terraform, men ikke umulig. OpenTofu er MPL 2.0, hostet af Linux Foundation, og et CNCF Sandbox-projekt siden 23. april 2025. Governance er multi-part, og licensen er OSI-godkendt. En ensidig relicensiering fra en enkelt grundlægger ville stride imod både fondens charter og de eksisterende MPL 2.0-bidrag, som skulle fjernes eller omskrives. Bekymringen er legitim; de strukturelle barrierer er reelle.

Hvad Betyder IBMs Opkøb af HashiCorp for Terraforms Fremtid?

IBM afsluttede opkøbet af HashiCorp den 27. februar 2025 for 6,4 milliarder dollar. Terraforms roadmap ligger nu inde i en større enterprise-leverandør. Opkøbet alene beviser ikke fremtidig licensiering eller produktretning; vurder aktuelle release notes, licensvejledning og HCP-produktændringer i stedet for at behandle ejerskab som en forudsigelse.

Er OpenTofu Klar til Produktion i 2026?

Ja. v1.12.5 er den aktuelle vedligeholdelsesudgivelse, projektet er i CNCF Sandbox, og Fidelity har beskrevet produktionsadoption på tværs af en IaC-infrastruktur med mere end 50.000 state-filer og fire millioner ressourcer. Klar til produktion betyder ikke funktionsidentisk: teams, der er afhængige af HCP-eksklusive funktioner som Terraform Stacks, skal stadig træffe en separat kompatibilitetsbeslutning.