OpenTofu vysvětleno: fork Terraformu, migrace a zda přejít

Otevřete dnes modul Terraformu a narazíte na otázku, která před třemi lety neexistovala: je binárka, která tento kód spouští, terraform, nebo je to tofu? Společnost IBM dokončila akvizici HashiCorp 27. února 2025 za 6,4 miliardy dolarů a OpenTofu se stalo sandboxovým projektem CNCF 23. dubna 2025 a cesta migrace mezi oběma nástroji je oficiálně zdokumentována. Rozhodnutí už není hypotetické.

Tento článek je napsán z pohledu provozu infrastruktury, nikoli z pohledu poskytovatele spravované platformy Terraform. Cílem je oddělit skutečné náklady na migraci od licenčního a governance šumu. To znamená, že mohu být upřímný ohledně toho, co se při migraci rozbije, jaké jsou oprávněné otázky governance a kdy je správnou volbou zůstat u Terraformu.

Tento článek se věnuje čtyřem věcem: co je OpenTofu v roce 2026, jaké funkce Terraform nemá, jak migrace vypadá v praxi a jasné doporučení pro běžné rozhodovací situace.

Zkrácená verze

• OpenTofu je open-source fork Terraformu s licencí MPL 2.0, hostovaný Linux Foundation a od 23. dubna 2025 sandboxovým projektem CNCF. Vznikl forkem z Terraformu 1.5.x poté, co HashiCorp v srpnu 2023 přesunul Terraform na Business Source License.
• K 26. červenci 2026 je aktuální udržovací verzí v1.12.5; repozitář na GitHubu má více než 29 000 hvězdiček a webu projektu OpenTofu uvádí přes 3 900 providerů a přes 23 600 modulů.
• Nabízí funkce dostupné pouze v OpenTofu nebo v nich OpenTofu vede a Terraform je aktuálně nemá ve stejné podobě: šifrování stavu a plánu na straně klienta, provider for_each, raným vyhodnocováním proměnných, enabled meta-argumentem a dynamickým prevent_destroy. Ephemeral resources nejsou exkluzivní pro OpenTofu; Terraform je podporuje od verze 1.10.
• U malého projektu na Terraformu 1.5.x s lokálním nebo S3 stavem může být přímočará cesta krátkou, vratnou migrací. Práce narůstá u odkazů v CI/CD, workflow specifických pro HCP a změn v dependency-lock souborech.
• U nového IaC projektu v roce 2026 začněte s OpenTofu. U existujícího nasazení Terraformu přejděte, když začne bolet BSL, když potřebujete funkci, kterou má OpenTofu a Terraform ne, nebo když je pro vás skutečným problémem plán vývoje pod IBM. Jinak je poměr přínosů a nákladů tenký.

Co je OpenTofu v roce 2026

OpenTofu je open-source fork Terraformu, hostovaný Linux Foundation, přijatý do CNCF jako sandboxový projekt 23. dubna 2025 a licencovaný pod Mozilla Public License 2.0. Binárka se jmenuje tofu. Konfigurační jazyk je HCL, stejné HCL, jaké používá Terraform. U většiny jednoduchých až středně složitých projektů běží existující kódová báze Terraformu na OpenTofu beze změny.

Fork vznikl v srpnu 2023 poté, co HashiCorp přesunul Terraform z MPL 2.0 na Business Source License 1.1 10. srpna 2023. BSL je source-available licence, nikoli licence schválená OSI, a omezuje produkční nasazení, které "konkuruje komerční nabídce HashiCorpu." Během pěti dnů byl zveřejněn OpenTF Manifesto a byl oznámen fork. Oznámení Linux Foundation formálně představilo OpenTofu 20. září 2023.

Oznámení Linux Foundation jmenovalo Harness, Gruntwork, Spacelift, env0, Scalr, Digger, Terrateam, Massdriver a Terramate mezi zakládající podporovatele, s minimálně 18 inženýry přislíbenými na plný úvazek na dobu nejméně pěti let. OpenTofu vzniklo forkem z Terraformu 1.5.x, poslední větve pod MPL 2.0.

Kde projekt dnes stojí: v1.12.5 je aktuální udržovací verze a oficiální web uvádí přes 3 900 providerů a přes 23 600 modulů. Signály o adopci už nejsou omezené jen na dynamiku protestního forku: případové studii migrace Fidelity popisuje program zahrnující více než 50 000 state souborů a čtyři miliony resourců.

Relevantní obchodní kontext: IBM dokončila akvizici HashiCorpu 27. února 2025 za 6,4 miliardy dolarů. Plán vývoje Terraformu je nyní stanoven uvnitř mnohem většího podnikového dodavatele. To pro uživatele automaticky neznamená dobrou ani špatnou zprávu, ale je to součást kalkulace, kterou týmy v roce 2026 dělají.

V čem se OpenTofu liší od Terraformu

Od forku se oba projekty vydaly odlišnými cestami vývoje funkcí. Tabulka níže je stručná verze; poznámky, které následují, vysvětlují, co každý rozdíl znamená pro praktiky.

Na straně klienta šifrování stavu (v1.7.0, 30. dubna 2024). OpenTofu umí zašifrovat state a plan soubory přímo v nástroji pomocí PBKDF2, AWS KMS, GCP KMS nebo OpenBao. Terraform obvykle deleguje šifrování v klidovém stavu na zvolený backend, zatímco lokální state zůstává v čitelném textu. Šifrování na straně klienta v OpenTofu dokáže ochránit odcizený state objekt nebo cachovaný plán, pokud s ním není vystaven i dešifrovací klíč. Nenahrazuje TLS, řízení přístupu k backendu ani disciplínu ve správě tajemství.

Konfigurace vypadá zhruba takto:

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

Poskytovatel for_each (v1.9). Konfigurace provideru můžete iterovat stejně jako resourcy. U nastavení s více regiony nebo účty to odstraňuje dlouhotrvající třídu obcházení. Už nemusíte ručně psát jeden aliasovaný provider pro každý region; jeden blok můžete řídit z mapy.

Rané vyhodnocování proměnných (v1.8). Proměnné lze nyní odkazovat na místech, kde to dříve bylo omezené, včetně argumentů backendu a zdroje modulu. To se hodí, když jeden root modul řídí více prostředí, která se liší malou sadou proměnných.

Ephemeral resources a enabled meta-argument (v1.11.0, 9. prosince 2025). OpenTofu 1.11 přidalo ephemeral resources a enabled meta-argument. Ephemeral resources existují jen v rámci jednoho cyklu plan/apply a neukládají se do stavu, což se hodí pro krátkodobé přihlašovací údaje. Nejsou exkluzivní pro OpenTofu: Terraform je zavedl ve verzi 1.10 a ve verzi 1.11 přidal write-only argumenty. Specifickou funkcí OpenTofu je zde enabled, který přepíná resource blok podle výrazu bez podmíněné count gymnastiky.

Dynamický prevent_destroy (v1.12). Nastavení prevent_destroy prevent_destroy v Terraformu přijímá pouze literální hodnoty. OpenTofu 1.12 umožňuje jej vypočítat, takže jeden modul může nechat staging zničitelný a zároveň chránit produkci.

Řádek s licencí je strukturální rozdíl, který se neprojevuje jako funkce. MPL 2.0 je schválená OSI a jde o copyleft na úrovni souboru. Licence Terraformu BSL 1.1 je source-available, obsahuje dodatečné omezení použití a čtyři roky po zveřejnění každého licencovaného díla se mění na MPL 2.0. Pro většinu týmů je praktický dopad malý; pro dodavatele, kteří staví něco blízkého komerční nabídce HashiCorpu, je to důvod, proč fork existuje.

Migrace: Co se skutečně rozbije

Oficiální průvodce migrací je záměrně krátký a vratný: zálohujte state a kód, nainstalujte OpenTofu, spusťte tofu init, porovnejte tofu plan, a otestujte malou změnu. Náročné nejsou příkazy. Náročné jsou okolní odkazy v CI/CD, workflow specifické pro HCP, změny v dependency-lock a organizační revize, která přichází s přijetím forku.

Přímočará cesta

U projektu, který nepoužívá HCP Terraform a nemá tisíc odkazů v pipeline na terraform, je migrace přímočará.

# 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 by měl odpovídat plánu, který vytvořil Terraform. Pokud se objeví neočekávaný rozdíl, zkontrolujte před apply verze providerů, nastavení backendu a jakékoli funkce Terraformu novější než 1.5.x.

Než cokoli spustíte, záleží na dvou nuancích. Zaprvé, OpenTofu je pro případy popsané v tomto průvodci obecně konfiguračně kompatibilní s HCL ve stylu Terraformu, ale funkce přidané po Terraformu 1.5.x je stále potřeba zkontrolovat na kompatibilitu. Zadruhé, tofu init -upgrade může aktualizovat .terraform.lock.hcl, včetně zdrojových adres providerů a checksum záznamů. Tato metadata posuzujte odděleně od infrastrukturního driftu.

Skutečné překážky

Tři věci mohou rychlou CLI migraci proměnit v širší platformový projekt. Žádná z nich není chyba.

Workspacy HCP Terraform. OpenTofu obsahuje cloud a remote integrace pro kompatibilní remote služby, včetně HCP Terraform ve scénářích lokálního spouštění a ukládání stavu. Náročnější je remote spouštění a platformní funkce specifické pro HCP: Sentinel, run triggers, dynamické přihlašovací údaje, Stacks a jakékoli chování služby, které OpenTofu nemůže plně otestovat nebo podporovat. Pokud jsou tyto věci klíčové, otestujte nejprve jeden workspace; pokud HCP opouštíte, migrujte state a znovu vytvořte tyto platformní kontroly.

Tip: Opuštění HCP Terraformu může být největší skrytý náklad, pokud infrastruktura závisí na workflow specifických pro HCP. Než se rozhodnete, spusťte terraform state pull > state.json a zkontrolujte velikost a počet resourců. Jeden workspace s 200 resourcy je jiný projekt než flotila 50 workspaců s run triggery a policy sety. To druhé je migrace na úrovni platform engineeringu, nikoli výměna nástroje.

CI/CD pipeline napevno navázané na terraform. Každý odkaz na terraform plan, terraform apply, cestu k binárce, Docker image a krok v GitHub Actions nebo GitLab CI je třeba zkontrolovat. U GitHub Actions vypadá výměna zhruba takto:

# 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

To je triviální případ: jeden workflow, jeden repozitář. V monorepu se sdílenými composite akcemi, více pipelinami a knihovnou opakovaně použitelných workflow je plocha pro revizi širší. Práce je mechanická, ale může trvat déle než výměna CLI.

Kontrola lock souboru závislostí. tofu init může aktualizovat .terraform.lock.hcl, včetně zdrojových adres providerů a checksum záznamů. OpenTofu 1.12 může navíc přidat kompletní h1: sady checksum pro všechny platformy. Berte tento diff jako metadata závislostí, která je třeba zkontrolovat a commitnout odděleně, ne jako infrastrukturní drift.

Tip: Diff lock souboru může při prvním commitu vypadat nepřehledně. Spusťte tofu init -upgrade na čisté větvi, commitněte pouze lock soubor s jasnou zprávou jako "review OpenTofu lock-file changes" a poté na něj rebasujte práci na funkci. Míchání metadat závislostí s feature PR ztěžuje kontrolu obou změn.

Odpor stakeholderů. "Teď provozujeme fork" zní v různých organizacích jinak. Poctivá odpověď je, že OpenTofu zůstává pro případy popsané v tomto průvodci konfiguračně kompatibilní s HCL ve stylu Terraformu, takže výměna je obvykle vratná. Kdyby OpenTofu zítra zmizelo, mnoho týmů by mohlo znovu nainstalovat Terraform, zkontrolovat lock soubor a dál používat stejné .tf soubory. Nejprve ověřte funkce přidané po forku; toto upozornění je věrohodnější než slibovat dokonalou zaměnitelnost.

Kdy je migrace opravdu obtížná

Tato přímočará cesta neplatí pro každou instalaci Terraformu.

Migrace se výrazně komplikuje, když:

• State je velký (tisíce resourců, desítky workspaců) a žije v HCP Terraformu.
• Kódová báze hluboce využívá funkce dostupné jen v HCP: Sentinel policy zapojené do workspaců, run triggery, dynamické přihlašovací údaje providerů spravované HCP. Terraform Stacks je exkluzivní pro HCP a nemá v OpenTofu ekvivalent, což je mimo rozsah tohoto článku.
• Podnikový audit nebo compliance framework výslovně jmenuje "Terraform" jako oficiální IaC nástroj, což je kromě technického problému i problém s nákupem a dokumentací.
• Velká knihovna modulů má interní omezení verzí, která se řešila podle registrového chování specifického pro Terraform.

Ne každý tým by měl migrovat. Poměr přínosů a nákladů dává smysl jen tehdy, když omezení BSL skutečně ovlivňuje váš use case, když konkrétní funkce OpenTofu odblokuje něco konkrétního, nebo když je pro vaši organizaci skutečným problémem plán vývoje pod kontrolou IBM. Pokud nic z toho neplatí, zůstat u Terraformu je zcela obhajitelné rozhodnutí.

Máte přejít?

Neexistuje jedna univerzálně správná odpověď. Když pro tým kreslím rozhodovací strom, objevují se čtyři běžné situace a správný krok závisí na tom, ve které z nich se nacházíte.

Nové zavedení IaC (greenfield). Začněte s OpenTofu. Licence je MPL 2.0, governance spadá pod Linux Foundation a CNCF a projekt má aktivní tempo vydávání verzí. Mezi jeho odlišující funkce patří šifrování stavu na straně klienta, provider for_each, enableda dynamickým prevent_destroy. Nemusíte plánovat kolem tření s BSL. Toto je nejsilnější doporučení v tomto článku.

Stávající uživatel Terraformu, malý až středně velký projekt. Přejděte, pokud nastane kterýkoli ze tří spouštěčů. Za prvé: prodáváte nebo byste mohli prodávat produkt, který by mohl narazit na výjimku BSL "konkuruje HashiCorpu"; právní kalkulace je u MPL 2.0 jednodušší. Za druhé: potřebujete šifrování stavu na straně klienta, provider for_each, enabled, nebo dynamický prevent_destroy a obcházení v Terraformu se už nevyplatí udržovat. Za třetí: dáváte přednost víceúčastnickému governance před plánem vývoje jednoho dodavatele. Pokud nic z toho neplatí a Terraform běží bez problémů, zůstaňte. Migrace je v mnoha infrastrukturách vratná, ale není zdarma.

Intenzivní uživatel HCP Terraformu. Berte to jako platformní rozhodnutí, nikoli automaticky jako migraci backendu. OpenTofu umí používat kompatibilní remote backendy, ale remote spouštění specifické pro HCP, Sentinel, run triggery, dynamické přihlašovací údaje a Stacks stále vyžadují posouzení funkce po funkci. Pokud jsou tyto kontroly klíčové, nejprve otestujte. Pokud HCP opouštíte z licenčních, nákladových nebo governance důvodů, plánujte práci jako platformní migraci.

Zvažujete Pulumi nebo jinou alternativu bez HCL. OpenTofu je nejbližší cesta, pokud chcete zachovat HCL a většinu stávajících workflow. Pulumi je širší platforma a volba jazyka: TypeScript, Python, Go nebo .NET řídící cloudová API. Přesun tam může zahrnovat konverzi nebo přepsání, takže jej vyhodnoťte odděleně od pouhé výměny binárky Terraform za OpenTofu.

Ještě jedna věc stojí za přímé řešení: oprávněná kritika, že OpenTofu je částečně zajištěním zájmů SaaS dodavatelů. Vlákno na Hacker News o změně BSL upozornilo na obavu, že zakládající členové projektu jsou komerční platformy postavené na Terraformu s vlastní motivací mít licenční flexibilitu. Tuto obavu beru vážně. Zmírňujícím faktorem je struktura governance, hosting u Linux Foundation, CNCF Sandbox, MPL 2.0 na každém souboru, což dělá budoucí relicencování výrazně těžším, než bylo relicencování jediným dodavatelem. Nedělá to relicencování nemožným. Dělá to však dost nákladným na to, aby to byla skutečná pojistka.

Rychlý verdikt. Pro novou práci s IaC v roce 2026 začněte s OpenTofu. Jeho licence, governance, aktivní vývoj a sada funkcí z něj dělají silnou výchozí volbu. U existujících nasazení Terraformu přejděte, když platí jeden ze tří výše uvedených spouštěčů; jinak je poměr přínosů a nákladů tenký a zůstat je v pořádku.

Jakmile je volba nástroje jasná, další praktickou otázkou je, kde by OpenTofu mělo běžet. Toto rozhodnutí ovlivňuje zacházení s tajemstvími, náklady, opakovatelnost a míru kontroly, kterou má váš tým nad prostředím spouštění.

Provoz OpenTofu vlastními silami

OpenTofu je CLI binárka. Kde ji spouštíte, výrazně určuje náklady, bezpečnost a to, co s ní můžete dělat. Existují zhruba tři rozumná místa, kam ji umístit.

Notebook nebo vývojářský stroj. V pořádku pro jednorázové plány, prototypování a malé osobní projekty. Je to špatná výchozí volba pro sdílené produkční workflow, pokud už není vynucen remote state, locking a disciplína revizí. Týmům obvykle prospívá kanonické prostředí spouštění místo toho, aby rozhodoval poslední notebook, na kterém běžel tofu apply.

Spravovaný CI runner (GitHub Actions, GitLab CI atd.). Běžná cesta. opentofu/setup-opentofu akce je přímou náhradou za hashicorp/setup-terraform. Pro většinu týmů a projektů to funguje dobře. Kompromisy: tajemství procházejí přes CI službu třetí strany, minuty na free tieru mohou u velkých operací se stavem dojít a prostředí runneru je efemérní, což je obvykle výhoda, ale někdy omezení. Podívejte se na GitHub vs GitLab pokud stále vybíráte mezi hostovanými CI možnostmi, a Best CI/CD Tools pro širší přehled.

Vlastní runner na VPS. Užitečné, když kompromisy spravovaného CI přestanou fungovat: tajemství musí zůstat mimo službu třetí strany, minuty CI se stanou drahými, nebo chcete perzistentní cache providerů. Nastavení je přímočaré: Linux VPS, binárka OpenTofu, agent GitHub Actions nebo GitLab Runner a Docker pro izolaci úloh. Podívejte se na Install Docker on VPS pokud je tato část pro vás nová. Pro runner malého týmu je rozumným výchozím bodem 4 GB RAM, 2 vCPU a 60 GB NVMe; CPU, paměť a úložiště škálujte pro větší plány a vyšší souběžnost.

Pro týmy, které potřebují přísnější kontrolu nad tajemstvími runneru, perzistentní cache providerů nebo předvídatelné náklady na CI, může dávat smysl vlastní runner na VPS. V takovém nastavení upřednostněte root přístup, rychlé NVMe úložiště, snadné škálování a dostatek CPU/RAM pro větší plánovací operace.

Cloudzy Linux VPS instance se do tohoto vzoru vlastního runneru hodí díky root přístupu, NVMe úložišti a flexibilnímu škálování, takže můžete začít v malém a runner škálovat s tím, jak rostou vaše pracovní zátěže OpenTofu.

Časté dotazy

Je OpenTofu totéž co Terraform?

Ne tak docela. OpenTofu vzniklo jako fork Terraformu 1.5.x a zůstává obecně konfiguračně kompatibilní s HCL ve stylu Terraformu: stejné .tf soubory, providery a plan/apply workflow pro mnoho projektů. Liší se v licenci a ve funkcích přidaných po forku. OpenTofu má šifrování stavu na straně klienta, provider for_each, enableda dynamickým prevent_destroy; Terraform má své vlastní funkce přidané po forku, včetně ephemeral resources.

Podpoří OpenTofu všechny mé providery z Terraformu?

U hlavních providerů, jako jsou AWS, GCP, Azure, Kubernetes a Helm, obecně ano. OpenTofu Registry uvádí přes 3 900 providerů k červenci 2026. tofu init může aktualizovat .terraform.lock.hcl metadata. U okrajových, dodavatelsky specifických nebo nově vydaných providerů si dostupnost a podporu verzí ověřte přímo předtím, než přejdete.

Mohlo by být OpenTofu jednou samo relicencováno?

Budoucí relicencování je těžší, než tomu bylo u Terraformu, ale není nemožné. OpenTofu je pod MPL 2.0, hostováno Linux Foundation a od 23. dubna 2025 sandboxovým projektem CNCF. Governance je víceúčastnická a licence je schválená OSI. Jednostranné relicencování jakýmkoli zakladatelem by bylo v rozporu jak s chartou nadace, tak se stávajícími příspěvky pod MPL 2.0, které by musely být odstraněny nebo přepsány. Obava je oprávněná; strukturální bariéry jsou reálné.

Co znamená akvizice HashiCorpu ze strany IBM pro budoucnost Terraformu?

IBM dokončila akvizici HashiCorpu 27. února 2025 za 6,4 miliardy dolarů. Plán vývoje Terraformu je nyní součástí většího podnikového dodavatele. Samotná akvizice nic nevypovídá o budoucí licenci ani směřování produktu; hodnoťte aktuální poznámky k vydání, licenční pokyny a změny produktů HCP, místo abyste vlastnictví brali jako předpověď.

Je OpenTofu v roce 2026 připravené pro produkci?

Ano. v1.12.5 je aktuální udržovací verze, projekt je v CNCF Sandbox a Fidelity popsala produkční nasazení napříč IaC infrastrukturou s více než 50 000 state soubory a čtyřmi miliony resourců. Připravenost pro produkci neznamená identičnost funkcí: týmy, které se spoléhají na funkce dostupné jen v HCP, jako je Terraform Stacks, stále potřebují samostatné rozhodnutí o kompatibilitě.