Az OpenTofu Elmagyarázva: A Terraform Forkja, a Migráció, és Hogy Érdemes-e Váltani

Nyisson meg ma egy Terraform modult, és egy három évvel ezelőtt még nem létező kérdéssel szembesül: az ezt a kódot futtató bináris terraform, vagy tofu? Az IBM lezárta a HashiCorp-felvásárlás 2025. február 27-én, 6,4 milliárd dollárért, az OpenTofu pedig CNCF Sandbox projekt 2025. április 23-án, és a két eszköz közötti migrációs útvonal hivatalosan is dokumentálva van. A döntés többé nem elméleti kérdés.

Ez a cikk infrastruktúra-üzemeltetési szemszögből íródott, nem egy felügyelt Terraform-platform nézőpontjából. A cél az, hogy szétválasszuk a valódi migrációs költségeket a licencelés és a governance körüli zajtól. Ez azt jelenti, hogy őszintén beszélhetek arról, mi törik el a migráció során, melyek a jogos governance-kérdések, és mely esetekben a Terraformon maradás a helyes döntés.

Ez a cikk négy dolgot tárgyal: mi az OpenTofu 2026-ban, milyen funkciók hiányoznak a Terraformból, hogyan néz ki a migráció a gyakorlatban, és egyértelmű ajánlást ad a leggyakoribb döntési helyzetekhez.

A rövid verzió

• Az OpenTofu a Terraform nyílt forráskódú forkja, MPL 2.0 licenc alatt, a Linux Foundation gondozásában, és 2025. április 23. óta CNCF Sandbox projekt. A Terraform 1.5.x ágából vált le, miután a HashiCorp 2023 augusztusában a Business Source License-re váltotta a Terraformot.
• 2026. július 26-i állapot szerint a jelenlegi karbantartási kiadás a v1.12.5; a GitHub-tárolónak több mint 29 000 csillagja van, és a OpenTofu projekt weboldala 3900+ providert és 23 600+ modult sorol fel.
• Olyan képességeket kínál, amelyek kizárólag az OpenTofuban léteznek, vagy amelyekben az OpenTofu vezet, és amelyeket a Terraform jelenleg nem tud ugyanúgy: kliensoldali state- és plan-titkosítás, provider for_each, korai változóértékelés, az enabled meta-argumentum, és dinamikus prevent_destroy. Az ephemeral resources nem kizárólag az OpenTofu sajátja; a Terraform az 1.10 óta támogatja őket.
• Egy kis, helyi vagy S3 state-et használó Terraform 1.5.x projekt esetén az ideális út egy rövid, visszafordítható migráció lehet. A CI/CD-hivatkozások, a HCP-specifikus workflow-k és a dependency-lock változásai azok, ahol a munka bővül.
• Egy 2026-os új IaC-projektnél kezdd az OpenTofuval. Egy meglévő Terraform-telepítésnél akkor válts, ha a BSL korlátozásai fájdalmasak, ha olyan funkcióra van szükséged, amely csak az OpenTofuban van meg, vagy ha az IBM-tulajdonú roadmap valós aggály. Egyébként a költség-haszon arány vékony.

Mi az OpenTofu 2026-ban

Az OpenTofu a Terraform nyílt forráskódú forkja, a Linux Foundation gondozásában, 2025. április 23-án felvették a CNCF-be Sandbox projektként, és a Mozilla Public License 2.0 alatt terjesztik. A bináris neve tofu. A konfigurációs nyelv a HCL, ugyanaz, amit a Terraform is használ. A legtöbb egyszerű-közepes projektnél egy meglévő Terraform-kódbázis változtatás nélkül fut OpenTofun.

A fork 2023 augusztusában indult, miután a HashiCorp az MPL 2.0-ról átvitte a Terraformot a Business Source License 1.1 2023. augusztus 10-i váltásával kezdődött. A BSL source-available, nem OSI-jóváhagyott licenc, és korlátozza azt a termelési használatot, amely "versenyez a HashiCorp kereskedelmi termékeivel." Öt napon belül megjelent az OpenTF kiáltvány, és bejelentették a forkot. A Linux Foundation bejelentése 2023. szeptember 20-án mutatta be hivatalosan az OpenTofut.

A Linux Foundation bejelentése megnevezte a Harness, Gruntwork, Spacelift, env0, Scalr, Digger, Terrateam, Massdriver és Terramate cégeket az alapító támogatók között, legalább 18 mérnök teljes munkaidős, legalább ötéves elköteleződésével. Az OpenTofu a Terraform 1.5.x ágából, az utolsó MPL 2.0-s verzióból vált le.

Hol tart ma a projekt: a v1.12.5 a jelenlegi karbantartási kiadás, a hivatalos oldal pedig 3900+ providert és 23 600+ modult sorol fel. Az elterjedés jelei már nem korlátozódnak a tiltakozó fork kezdeti lendületére: egy Fidelity migrációs esettanulmány több mint 50 000 state-fájlt és négymillió erőforrást felölelő programot mutat be.

A releváns üzleti háttér: az IBM 2025. február 27-én, 6,4 milliárd dollárért lezárta a HashiCorp felvásárlását. A Terraform roadmapje mostantól egy sokkal nagyobb vállalati beszállító keretein belül alakul. Ez önmagában nem jó vagy rossz a felhasználók számára, de része annak a mérlegelésnek, amelyet a csapatok 2026-ban végeznek.

Miben Különbözik az OpenTofu a Terraformtól

A fork óta a két projekt eltérő funkcionális irányt vett. Az alábbi táblázat a rövid verzió; az azt követő megjegyzések elmagyarázzák, mit jelent az egyes különbség a gyakorlatban.

Kliensoldali state-titkosítás (v1.7.0, 2024. április 30.). Az OpenTofu az eszközön belül képes titkosítani a state- és plan-fájlokat PBKDF2, AWS KMS, GCP KMS vagy OpenBao segítségével. A Terraform általában a kiválasztott backendre bízza a nyugalmi állapotú titkosítást, míg a helyi state sima szövegként marad. Az OpenTofu kliensoldali titkosítása megvédhet egy ellopott state-objektumot vagy gyorsítótárazott plant, feltéve, hogy a visszafejtő kulcs nem kerül vele együtt nyilvánosságra. Nem helyettesíti a TLS-t, a backend hozzáférés-vezérlést vagy a secret-kezelési fegyelmet.

A konfiguráció nagyjából így néz ki:

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

Szolgáltató for_each (v1.9). A provider-konfigurációkat ugyanúgy iterálhatod, mint az erőforrásokat. Több régiós vagy több fiókos beállításoknál ez megszüntet egy régóta fennálló workaround-osztályt. Többé nem kell régiónként kézzel megírt aliasolt providert létrehoznod; egyetlen blokkból, egy map alapján is vezérelheted.

Korai változóértékelés (v1.8). A változók olyan helyeken is hivatkozhatók, ahol korábban ez tiltott volt, ideértve a backend és a module source argumentumokat is. Ez akkor hasznos, ha egyetlen root modul több olyan környezetet vezérel, amelyek csak néhány változóban térnek el egymástól.

Az ephemeral resources és a enabled meta-argumentum (v1.11.0, 2025. december 9.). Az OpenTofu 1.11 hozzáadta az ephemeral resources funkciót és a enabled meta-argumentumot. Az ephemeral resources csak egyetlen plan/apply ciklus keretében léteznek, és nem maradnak fenn a state-ben, ami rövid élettartamú hitelesítő adatoknál hasznos. Nem kizárólag az OpenTofu sajátjai: a Terraform az 1.10-ben vezette be őket, majd az 1.11-ben write-only argumentumokat is hozzáadott. Az OpenTofu-specifikus képesség itt a enabled, amely egy kifejezés alapján kapcsolja be vagy ki egy resource blokkot, feltételes count trükközés nélkül.

Dinamikus prevent_destroy (v1.12). A Terraform prevent_destroy beállítása csak literál értékeket fogad el. Az OpenTofu 1.12 lehetővé teszi a kiszámítását, így egyetlen modul megtarthatja a staginget törölhetőnek, miközben megvédi a productiont.

A licenc-sor az a strukturális különbség, amely nem funkcióként jelenik meg. Az MPL 2.0 OSI által jóváhagyott, fájlszintű copyleft licenc. A Terraform BSL 1.1 licence source-available, tartalmaz egy további felhasználási korlátozást, és minden egyes licencelt mű megjelenése után négy évvel MPL 2.0-ra vált. A legtöbb csapat számára ennek gyakorlati hatása csekély; azoknak a beszállítóknak viszont, akik a HashiCorp kereskedelmi termékeihez közeli valamit építenek, ez az oka annak, hogy a fork létezik.

Migráció: Mi Törik El Valójában

A hivatalos migrációs útmutató szándékosan rövid és visszafordítható: készíts biztonsági mentést a state-ről és a kódról, telepítsd az OpenTofut, futtasd a tofu init, hasonlítsd össze a tofu plan, és teszteld egy kis változtatással. A nehéz részek nem a parancsok. Hanem a környező CI/CD-hivatkozások, a HCP-specifikus workflow-k, a dependency-lock változásai, valamint a fork bevezetésével járó szervezeti felülvizsgálat.

A Zökkenőmentes Út

Egy olyan projektnél, amely nem használ HCP Terraformot, és nincs ezernyi pipeline-hivatkozása a terraformhivatkozásra, a migráció egyszerű.

# 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 eredményének meg kell egyeznie a Terraform által készített plannel. Ha váratlan eltérést találsz, ellenőrizd a provider-verziókat, a backend-beállításokat és az 1.5.x utáni Terraform-funkciókat, mielőtt alkalmaznád.

Két árnyalatnyi részlet számít, mielőtt bármit is futtatnál. Először: az OpenTofu nagyrészt konfigurációkompatibilis a Terraform-stílusú HCL-lel az ebben az útmutatóban leírt esetekben, de a Terraform 1.5.x után hozzáadott funkciók még mindig kompatibilitás-ellenőrzést igényelnek. Másodszor, tofu init -upgrade frissítheti a .terraform.lock.hcl-t, beleértve a provider source-címeket és a checksum-bejegyzéseket. Ezeket a metaadatokat az infrastruktúra-drifttől külön vizsgáld felül.

A Valódi Akadályok

Három dolog alakíthat egy gyors CLI-migrációt szélesebb platformprojektté. Ezek egyike sem hiba.

HCP Terraform workspace-ek. Az OpenTofu tartalmaz cloud és remote integrációkat kompatibilis remote szolgáltatásokhoz, beleértve a HCP Terraformot helyi végrehajtási és state-tárolási forgatókönyvekben. A nehezebb rész a HCP-specifikus remote végrehajtás és platformfunkciók: Sentinel, run triggerek, dinamikus hitelesítő adatok, Stacks, valamint bármely olyan szolgáltatásviselkedés, amelyet az OpenTofu nem tud teljes körűen tesztelni vagy támogatni. Ha ezek kulcsfontosságúak, először pilotolj egy workspace-en; ha elhagyod a HCP-t, migráld a state-et, és építsd újra ezeket a platformvezérlőket.

Profi tipp: A HCP Terraform elhagyása lehet a legnagyobb rejtett költség, ha a rendszer HCP-specifikus workflow-kra támaszkodik. Mielőtt döntenél, futtasd le a terraform state pull > state.json -t, és nézd meg a méretet és az erőforrások számát. Egy 200 erőforrást tartalmazó workspace más projekt, mint egy 50 workspace-ből álló flotta run triggerekkel és policy setekkel. Az utóbbi platformmérnöki migráció, nem egyszerű eszközcsere.

A terraformra hardkódolt CI/CD-pipeline-ok terraform. Minden hivatkozás a terraform plan, terraform apply, a bináris elérési útra, a Docker image-re, valamint a GitHub Actions vagy GitLab CI lépésre felül kell vizsgálni. GitHub Actions esetén a csere nagyjából így néz ki:

# 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

Ez a triviális eset: egy workflow, egy repó. Egy monorepóban, ahol megosztott composite action-ök, több pipeline és egy újrafelhasználható workflow-könyvtár van, a felülvizsgálandó terület jóval nagyobb. A munka mechanikus, de tovább tarthat, mint maga a CLI-csere.

A dependency lock-fájl felülvizsgálata. tofu init frissítheti a .terraform.lock.hcl-t, beleértve a provider source-címeket és a checksum-bejegyzéseket. Az OpenTofu 1.12 teljes h1: checksum-készleteket is hozzáadhat minden platformhoz. A diffet dependency-metaadatként kezeld, amelyet külön kell felülvizsgálni és commitolni, nem infrastruktúra-driftként.

Profi tipp: a lock-fájl diffje zajosnak tűnhet az első commitnál. Futtasd le a tofu init -upgrade egy tiszta branchen, commitolja csak a lock fájlt egy világos üzenettel, például "review OpenTofu lock-file changes", majd rebase-elje rá a feature munkát. A függőségi metaadatok összekeverése egy feature PR-ral mindkét változtatást nehezebbé teszi átnézni.

Stakeholderi ellenállás. A "most már egy forkot futtatunk" kijelentés szervezetenként eltérően csapódik le. Az őszinte válasz az, hogy az OpenTofu nagyrészt konfigurációkompatibilis marad a Terraform-stílusú HCL-lel az ebben az útmutatóban leírt esetekben, így a csere általában visszafordítható. Ha az OpenTofu holnap eltűnne, sok csapat egyszerűen újratelepíthetné a Terraformot, felülvizsgálhatná a lock fájlt, és folytathatná ugyanazoknak a .tf fájloknak. Először validáld a fork utáni funkciókat; ez a figyelmeztetés hitelesebb, mint a tökéletes felcserélhetőség ígérete.

Amikor a Migráció Valóban Nehéz

Ez a zökkenőmentes út nem érvényes minden Terraform-rendszerre.

A migráció érdemben nehezebbé válik, ha:

• A state nagy (több ezer erőforrás, több tucat workspace), és HCP Terraformban él.
• A kódbázis mélyen kihasználja a csak HCP-ben elérhető funkciókat: workspace-ekbe bekötött Sentinel-szabályzatokat, run triggereket, HCP által kezelt dinamikus provider hitelesítő adatokat. A Terraform Stacks csak HCP-ben érhető el, és nincs OpenTofu megfelelője, ez a témán kívül esik.
• Egy vállalati audit vagy megfelelőségi keretrendszer a "Terraformot" nevezi meg hivatalos IaC-eszközként, ami a technikai probléma tetejébe egy beszerzési és dokumentációs problémát is jelent.
• Egy nagy modulkönyvtár olyan belső verziómegkötésekkel rendelkezik, amelyek Terraform-specifikus registry-viselkedés alapján lettek feloldva.

Nem minden csapatnak érdemes migrálnia. A költség-haszon mérleg csak akkor van értelme, ha a BSL korlátozásai valóban érintik a use case-edet, ha egy konkrét OpenTofu-funkció old meg valamit, vagy ha az IBM által irányított roadmap valós aggály a szervezeted számára. Ha ezek egyike sem áll fenn, a Terraformon maradás teljesen indokolható döntés.

Érdemes Váltanod?

Itt nincs egyetlen helyes válasz. Amikor egy csapat számára felrajzolom a döntési fát, négy gyakori mintázat bukkan fel, és a helyes lépés attól függ, melyikbe tartozol.

Új IaC-bevezetés (greenfield). Kezdd az OpenTofuval. A licenc MPL 2.0, a governance a Linux Foundation és a CNCF alatt van, és a projekt aktív kiadási ütemet tart. Megkülönböztető jegyei közé tartozik a kliensoldali state-titkosítás, a provider for_each, enabled, valamint dinamikus prevent_destroy. Nincs BSL-súrlódás, amivel tervezni kellene. Ez a cikk legerősebb ajánlása.

Meglévő Terraform-felhasználó, kis-közepes projekt. Válts, ha a három kiváltó ok közül bármelyik fennáll. Egy: olyan terméket adsz el vagy adhatsz el, amely érintheti a BSL "versenyez a HashiCorppal" kivételét; a jogi helyzet tisztább MPL 2.0 alatt. Kettő: kliensoldali state-titkosításra, provider for_each, enabled, vagy dinamikus prevent_destroy van szükséged, és a Terraform-workaround fenntartása már nem éri meg. Három: a többszereplős governance-t részesíted előnyben az egyetlen szállítótól függő roadmappal szemben. Ha egyik sem áll fenn, és a Terraform hibátlanul fut, maradj. A migráció sok rendszerben visszafordítható, de nem ingyenes.

Intenzív HCP Terraform-felhasználó. Kezeld ezt platformdöntésként, ne automatikusan backend-migrációként. Az OpenTofu képes kompatibilis remote backendeket használni, de a HCP-specifikus remote végrehajtás, a Sentinel, a run triggerek, a dinamikus hitelesítő adatok és a Stacks továbbra is funkciónkénti felmérést igényelnek. Ha ezek a vezérlők kulcsfontosságúak, először pilotolj. Ha licencelési, költség- vagy governance-okokból hagyod el a HCP-t, a munkát platformmigrációként tervezd meg.

Fontolgatod a Pulumit vagy egy másik, nem HCL-alapú alternatívát. Az OpenTofu a legközelebbi út, ha meg akarod tartani a HCL-t és a legtöbb meglévő workflow-t. A Pulumi egy szélesebb platform- és nyelvválasztás: TypeScript, Python, Go vagy .NET vezérli a cloud API-kat. Az áttérés konverziót vagy újraírást igényelhet, ezért ezt külön értékeld a Terraformról OpenTofura történő egyszerű bináris váltástól.

Van még egy dolog, amit érdemes közvetlenül megemlíteni: az a jogos kritika, hogy az OpenTofu részben egyfajta SaaS-szolgáltatói fedezet. Egy Hacker News-fórumszál a BSL-változásról felvetette azt az aggályt, hogy a projekt alapító tagjai kereskedelmi Terraform-platformok, saját licencrugalmassági érdekkel. Ezt az aggályt komolyan veszem. Az enyhítő tényező a governance-struktúra, a Linux Foundation általi hosztolás, a CNCF Sandbox, valamint az MPL 2.0 minden fájlon, ami jelentősen megnehezíti a jövőbeli relicenszelést ahhoz képest, amilyen egyetlen szállító relicenszelése volt. Ez nem teszi lehetetlenné. De elég költségessé teszi ahhoz, hogy valódi fékként működjön.

Gyors összegzés. Egy 2026-os új IaC-munkánál kezdd az OpenTofuval. A licence, a governance, az aktív fejlesztés és a funkciókészlet erős alapértelmezett választássá teszi. A meglévő Terraform-telepítéseknél akkor válts, ha a fenti három kiváltó ok egyike fennáll; egyébként a költség-haszon arány vékony, és nyugodtan maradhatsz.

Ha az eszközválasztás egyértelmű, a következő gyakorlati kérdés az, hogy hol fusson az OpenTofu. Ez a döntés befolyásolja a secretek kezelését, a költséget, a reprodukálhatóságot, és azt, mennyire van kontrollod a csapatodnak a végrehajtási környezet felett.

Az OpenTofu Önálló Futtatása

Az OpenTofu egy CLI-bináris. Az, hogy hol futtatod, sokat meghatároz a költségről, a biztonságról és arról, mit tehetsz vele. Nagyjából három ésszerű hely van, ahová elhelyezheted.

Laptop vagy fejlesztői gép. Alkalmi plan-ekhez, prototípuskészítéshez és kis, személyes projektekhez megfelelő. Rossz alapértelmezett választás megosztott éles workflow-khoz, hacsak a remote state, a locking és a review-fegyelem már nincs érvényben. A csapatok általában jobban járnak egy kanonikus végrehajtási környezettel, mint azzal, hogy melyik laptopon futott legutóbb a tofu apply.

Felügyelt CI-runner (GitHub Actions, GitLab CI stb.). A megszokott út. A opentofu/setup-opentofu action közvetlen helyettesítője a hashicorp/setup-terraformhashicorp/setup-terraformnak. Ez a legtöbb csapatnál és projektnél jól működik. Kompromisszumok: a secretek egy harmadik féltől származó CI-szolgáltatáson haladnak át, az ingyenes csomag percei elfogyhatnak nagy state-műveleteknél, és a runner-környezet efemer, ami általában előny, de néha korlátozás is. Lásd: GitHub vs GitLab ha még mindig a hosztolt CI-lehetőségek közül választasz, és Best CI/CD Tools a tágabb áttekintésért.

Önhosztolt runner egy VPS-en. Akkor hasznos, ha a felügyelt CI kompromisszumai már nem működnek: a secreteknek távol kell maradniuk egy harmadik féltől származó szolgáltatástól, a CI-percek drágává válnak, vagy állandó provider-gyorsítótárakat szeretnél. A beállítás egyszerű: egy Linux VPS, az OpenTofu bináris, egy GitHub Actions vagy GitLab Runner ügynök, valamint Docker a jobok elkülönítéséhez. Lásd: Install Docker on VPS ha ez a rész új számodra. Egy kis csapat runneréhez 4 GB RAM, 2 vCPU és 60 GB NVMe ésszerű kiindulópont; skálázd a CPU-t, a memóriát és a tárhelyet nagyobb plan-ekhez és magasabb párhuzamossághoz.

Azoknak a csapatoknak, akiknek szorosabb kontrollra van szükségük a runner secretjei felett, állandó provider-gyorsítótárakra vagy kiszámítható CI-költségekre van szükségük, egy VPS-en futó önhosztolt runner ésszerű választás lehet. Ebben a beállításban helyezz előtérbe a root hozzáférést, a gyors NVMe-tárolót, a könnyű átméretezést és a nagyobb plan-műveletekhez elegendő CPU/RAM-ot.

Cloudzy Linux VPS -példányok illeszkednek ehhez az önhosztolt runner mintázathoz, root hozzáféréssel, NVMe-tárolóval és rugalmas méretezéssel, így kicsiben kezdheted, majd skálázhatod a runnert, ahogy az OpenTofu-terheléseid nőnek.

Gyakran ismételt kérdések

Az OpenTofu Ugyanaz, Mint a Terraform?

Nem egészen. Az OpenTofu a Terraform 1.5.x forkjaként indult, és nagyrészt konfigurációkompatibilis maradt a Terraform-stílusú HCL-lel: ugyanazok a .tf fájlok, providerek, és plan/apply workflow áll rendelkezésre sok projekthez. A licencben és a fork utáni funkciókban térnek el. Az OpenTofu rendelkezik kliensoldali state-titkosítással, provider for_each, enabled, valamint dinamikus prevent_destroy; a Terraformnak megvannak a saját fork utáni funkciói, köztük az ephemeral resources.

Az OpenTofu Támogatni Fogja Az Összes Terraform Providermet?

A nagyobb providerek, mint az AWS, GCP, Azure, Kubernetes és Helm esetében, általában igen. A OpenTofu Registry 2026 júliusi állapot szerint 3900+ providert jelent. tofu init frissítheti a .terraform.lock.hcl metaadatokat frissítheti. Niche, gyártóspecifikus vagy újonnan megjelent providerek esetén ellenőrizd közvetlenül az elérhetőséget és a verziótámogatást, mielőtt váltanál.

Előfordulhat, Hogy Egyszer Az OpenTofut Is Újralicencelik?

Egy jövőbeli relicenszelés nehezebb, mint amilyen a Terraformnál volt, de nem lehetetlen. Az OpenTofu MPL 2.0 licencű, a Linux Foundation gondozásában áll, és 2025. április 23. óta CNCF Sandbox projekt. A governance többszereplős, a licenc pedig OSI által jóváhagyott. Egy egyoldalú relicenszelés bármelyik alapítótól ütközne mind az alapítvány alapszabályával, mind a meglévő MPL 2.0-s hozzájárulásokkal, amelyeket el kellene távolítani vagy újra kellene írni. Az aggály jogos; a strukturális akadályok valósak.

Mit Jelent a HashiCorp IBM Általi Felvásárlása a Terraform Jövőjére Nézve?

Az IBM 2025. február 27-én, 6,4 milliárd dollárért lezárta a HashiCorp felvásárlását. A Terraform roadmapje mostantól egy nagyobb vállalati beszállítón belül alakul. Önmagában a felvásárlás nem bizonyítja a jövőbeli licencelési vagy termékirányt; a jelenlegi release note-okat, a licencelési útmutatást és a HCP-termékváltozásokat érdemes vizsgálni, nem a tulajdonjogot előrejelzésként kezelni.

Az OpenTofu Éles Környezetben Bevethető 2026-ban?

Igen. A v1.12.5 a jelenlegi karbantartási kiadás, a projekt a CNCF Sandbox része, és a Fidelity olyan éles bevezetésről számolt be, amely több mint 50 000 state-fájlt és négymillió erőforrást felölelő IaC-rendszerre terjed ki. Az éles bevethetőség nem jelent funkcionális azonosságot: azoknak a csapatoknak, amelyek olyan, csak HCP-ben elérhető képességekre támaszkodnak, mint a Terraform Stacks, továbbra is külön kompatibilitási döntést kell hozniuk.