OpenTofu wyjaśnione: fork Terraforma, migracja i czy warto się przełączyć

Otwórz dziś moduł Terraform, a staniesz przed pytaniem, które trzy lata temu nie istniało: czy plik binarny uruchamiający ten kod to terraform, czy może to tofu? Firma IBM zakończyła przejęcie HashiCorp 27 lutego 2025 roku za 6,4 miliarda dolarów, a OpenTofu stało się projektem sandboksowym CNCF 23 kwietnia 2025 roku, a ścieżka migracji między oboma narzędziami jest oficjalnie udokumentowana. Ta decyzja nie jest już hipotetyczna.

Ten artykuł napisano z perspektywy operacji infrastrukturalnych, a nie z perspektywy zarządzanej platformy Terraform. Celem jest oddzielenie rzeczywistych kosztów migracji od szumu związanego z licencjonowaniem i zarządzaniem projektem. Oznacza to, że mogę szczerze mówić o tym, co się psuje podczas migracji, jakie są uzasadnione pytania dotyczące governance oraz kiedy pozostanie przy Terraformie jest właściwym wyborem.

Ten artykuł obejmuje cztery kwestie: czym jest OpenTofu w 2026 roku, jakich funkcji brakuje w Terraformie, jak migracja wygląda w praktyce, oraz jasną rekomendację dla typowych scenariuszy decyzyjnych.

Krótka wersja

• OpenTofu to fork open source Terraforma na licencji MPL 2.0, hostowany przez Linux Foundation i będący projektem sandboksowym CNCF od 23 kwietnia 2025 roku. Powstał jako fork Terraforma 1.5.x po tym, jak HashiCorp w sierpniu 2023 roku przeniósł Terraform na licencję Business Source License.
• Na dzień 26 lipca 2026 roku aktualną wersją serwisową jest v1.12.5; repozytorium na GitHubie ma ponad 29 000 gwiazdek, a witryna projektu OpenTofu wymienia ponad 3900 dostawców i ponad 23 600 modułów.
• Zawiera funkcje dostępne wyłącznie w OpenTofu lub takie, w których OpenTofu przoduje, a których Terraform obecnie nie ma w tej samej postaci: szyfrowanie stanu i planu po stronie klienta, provider for_each, wczesną ewaluacją zmiennych, enabled meta-argumentem oraz dynamicznym prevent_destroy. Ephemeral resources nie są funkcją wyłącznie OpenTofu; Terraform obsługuje je od wersji 1.10.
• W przypadku małego projektu na Terraform 1.5.x z lokalnym stanem lub stanem w S3, prosta ścieżka migracji może być krótka i odwracalna. Nakład pracy rośnie przy odwołaniach w CI/CD, przepływach specyficznych dla HCP oraz zmianach w plikach blokady zależności.
• W przypadku nowego projektu IaC w 2026 roku zacznij od OpenTofu. W przypadku istniejącego wdrożenia Terraforma przejdź na OpenTofu, gdy zaczyna doskwierać BSL, gdy potrzebujesz funkcji, którą ma OpenTofu, a nie ma jej Terraform, lub gdy realnym problemem jest plan rozwoju kontrolowany przez IBM. W przeciwnym razie bilans korzyści do kosztów jest niewielki.

Czym jest OpenTofu w 2026 roku

OpenTofu to fork open source Terraforma, hostowany przez Linux Foundation, przyjęty do CNCF jako projekt sandboksowy 23 kwietnia 2025 roku i licencjonowany na Mozilla Public License 2.0. Plik binarny nosi nazwę tofu. Językiem konfiguracji jest HCL, ten sam HCL, którego używa Terraform. W przypadku większości prostych i średnio złożonych projektów istniejąca baza kodu Terraforma działa na OpenTofu bez zmian.

Fork powstał w sierpniu 2023 roku, po tym jak HashiCorp przeniósł Terraform z licencji MPL 2.0 na Business Source License 1.1 10 sierpnia 2023 roku. BSL to licencja typu source-available, a nie licencja zatwierdzona przez OSI, i ogranicza użycie produkcyjne, które "konkuruje z komercyjną ofertą HashiCorp". W ciągu pięciu dni opublikowano OpenTF Manifesto i ogłoszono forka. Oficjalne ogłoszenie Linux Foundation formalnie przedstawiło OpenTofu 20 września 2023 roku.

Ogłoszenie Linux Foundation wymieniło Harness, Gruntwork, Spacelift, env0, Scalr, Digger, Terrateam, Massdriver i Terramate wśród podmiotów założycielskich, z co najmniej 18 inżynierami zadeklarowanymi na pełny etat na minimum pięć lat. OpenTofu powstało jako fork Terraforma 1.5.x, ostatniej gałęzi na licencji MPL 2.0.

Gdzie projekt jest dziś: v1.12.5 to aktualna wersja serwisowa, a oficjalna strona wymienia ponad 3900 dostawców i ponad 23 600 modułów. Sygnały adopcji nie ograniczają się już do impetu protestacyjnego forka: studium przypadku migracji Fidelity opisuje program obejmujący ponad 50 000 plików stanu i cztery miliony zasobów.

Istotny kontekst biznesowy: IBM zakończyło przejęcie HashiCorp 27 lutego 2025 roku za 6,4 miliarda dolarów. Plan rozwoju Terraforma jest teraz ustalany wewnątrz znacznie większego dostawcy korporacyjnego. To nie jest automatycznie dobre ani złe dla użytkowników, ale stanowi część kalkulacji, jaką zespoły przeprowadzają w 2026 roku.

Czym OpenTofu różni się od Terraforma

Od momentu forka oba projekty poszły różnymi ścieżkami rozwoju funkcji. Poniższa tabela to skrócona wersja; następujące po niej uwagi wyjaśniają, co każda różnica oznacza w praktyce.

Po stronie klienta szyfrowanie stanu (v1.7.0, 30 kwietnia 2024). OpenTofu potrafi szyfrować pliki stanu i planu bezpośrednio w narzędziu za pomocą PBKDF2, AWS KMS, GCP KMS lub OpenBao. Terraform zazwyczaj deleguje szyfrowanie w spoczynku do wybranego backendu, podczas gdy lokalny stan pozostaje w postaci jawnego tekstu. Szyfrowanie po stronie klienta w OpenTofu może chronić skradziony obiekt stanu lub zbuforowany plan, pod warunkiem że klucz deszyfrujący nie zostanie ujawniony razem z nim. Nie zastępuje TLS, kontroli dostępu do backendu ani dyscypliny zarządzania sekretami.

Konfiguracja wygląda mniej więcej tak:

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

Dostawca for_each (v1.9). Konfiguracje dostawcy można iterować tak samo jak zasoby. W konfiguracjach obejmujących wiele regionów lub kont eliminuje to długo utrzymującą się klasę obejść. Nie musisz już ręcznie tworzyć jednego aliasowanego dostawcy dla każdego regionu; jeden blok możesz sterować z mapy.

Wczesna ewaluacja zmiennych (v1.8). Zmienne można teraz odwoływać w miejscach wcześniej ograniczonych, w tym w argumentach backendu i źródła modułu. Jest to przydatne, gdy jeden moduł główny obsługuje wiele środowisk różniących się niewielkim zestawem zmiennych.

Ephemeral resources i enabled meta-argument (v1.11.0, 9 grudnia 2025). OpenTofu 1.11 dodało ephemeral resources oraz enabled meta-argument. Ephemeral resources istnieją tylko w ramach jednego cyklu plan/apply i nie są zapisywane w stanie, co jest przydatne dla krótkotrwałych poświadczeń. Nie są funkcją wyłącznie OpenTofu: Terraform wprowadził je w wersji 1.10 i dodał argumenty write-only w wersji 1.11. Funkcją specyficzną dla OpenTofu jest tutaj enabled, który przełącza blok zasobu na podstawie wyrażenia bez warunkowej count gimnastyki.

Dynamiczny prevent_destroy (v1.12). Ustawienie prevent_destroy prevent_destroy w Terraformie akceptuje wyłącznie wartości literalne. OpenTofu 1.12 pozwala je obliczać, dzięki czemu jeden moduł może zachować możliwość usunięcia środowiska staging, jednocześnie chroniąc produkcję.

Wiersz z licencją to różnica strukturalna, która nie objawia się jako funkcja. MPL 2.0 jest zatwierdzona przez OSI i stanowi copyleft na poziomie pliku. Licencja Terraforma BSL 1.1 jest typu source-available, zawiera dodatkowe ograniczenie użycia i zmienia się na MPL 2.0 cztery lata po opublikowaniu każdego licencjonowanego dzieła. Dla większości zespołów praktyczny efekt jest niewielki; dla dostawców budujących cokolwiek zbliżonego do komercyjnej oferty HashiCorp jest to powód istnienia forka.

Migracja: co naprawdę się psuje

Oficjalny przewodnik migracji jest celowo krótki i odwracalny: wykonaj kopię zapasową stanu i kodu, zainstaluj OpenTofu, uruchom tofu init, porównaj tofu plan, i przetestuj drobną zmianę. Trudne nie są komendy. Trudne są otaczające odwołania w CI/CD, przepływy specyficzne dla HCP, zmiany w blokadzie zależności oraz przegląd organizacyjny, który towarzyszy przyjęciu forka.

Prosta ścieżka

W przypadku projektu, który nie korzysta z HCP Terraform i nie ma tysiąca odwołań w pipeline do terraform, migracja jest prosta.

# 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 powinien odpowiadać planowi wygenerowanemu przez Terraform. Jeśli pojawi się nieoczekiwana różnica, przed zastosowaniem sprawdź wersje dostawców, ustawienia backendu i wszelkie funkcje Terraforma nowsze niż 1.5.x.

Zanim cokolwiek uruchomisz, liczą się dwie subtelności. Po pierwsze, OpenTofu jest ogólnie kompatybilne pod względem konfiguracji z HCL w stylu Terraforma dla przypadków opisanych w tym przewodniku, ale funkcje dodane po Terraformie 1.5.x nadal wymagają sprawdzenia kompatybilności. Po drugie, tofu init -upgrade może zaktualizować .terraform.lock.hcl, w tym adresy źródłowe dostawców i wpisy sum kontrolnych. Te metadane oceniaj osobno od dryfu infrastruktury.

Prawdziwe przeszkody

Trzy rzeczy mogą zamienić szybką migrację CLI w szerszy projekt platformowy. Żadna z nich nie jest błędem.

Obszary robocze HCP Terraform. OpenTofu zawiera integracje cloud i remote dla kompatybilnych usług zdalnych, w tym HCP Terraform w scenariuszach lokalnego wykonywania i przechowywania stanu. Trudniejszą częścią jest zdalne wykonywanie i funkcje platformowe specyficzne dla HCP: Sentinel, run triggers, dynamiczne poświadczenia, Stacks oraz wszelkie zachowania usługi, których OpenTofu nie może w pełni przetestować ani obsłużyć. Jeśli są one kluczowe, przetestuj najpierw jeden obszar roboczy; jeśli opuszczasz HCP, zmigruj stan i odtwórz te mechanizmy kontroli platformy.

Wskazówka: Odejście od HCP Terraform może być największym ukrytym kosztem, gdy środowisko opiera się na przepływach specyficznych dla HCP. Zanim podejmiesz decyzję, uruchom terraform state pull > state.json i sprawdź rozmiar oraz liczbę zasobów. Jeden obszar roboczy z 200 zasobami to inny projekt niż flota 50 obszarów roboczych z run triggers i zestawami polityk. To drugie to migracja platform-engineeringowa, a nie wymiana narzędzia.

Potoki CI/CD zakodowane na sztywno dla terraform. Każde odwołanie do terraform plan, terraform apply, ścieżkę do pliku binarnego, obraz Dockera i krok w GitHub Actions lub GitLab CI wymaga przeglądu. W przypadku GitHub Actions zamiana wygląda mniej więcej tak:

# 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 trywialny przypadek: jeden workflow, jedno repozytorium. W monorepo ze współdzielonymi composite actions, wieloma potokami i biblioteką wielokrotnego użytku workflow, obszar przeglądu jest szerszy. Praca jest mechaniczna, ale może zająć więcej czasu niż wymiana CLI.

Przegląd pliku blokady zależności. tofu init może zaktualizować .terraform.lock.hcl, w tym adresy źródłowe dostawców i wpisy sum kontrolnych. OpenTofu 1.12 może również dodać kompletne h1: zestawy sum kontrolnych dla wszystkich platform. Traktuj tę różnicę jako metadane zależności do przeglądu i osobnego commitowania, a nie jako dryf infrastruktury.

Wskazówka: Różnica w pliku blokady może wyglądać na chaotyczną przy pierwszym commicie. Uruchom tofu init -upgrade na czystej gałęzi, zacommituj tylko plik blokady z jasnym komunikatem w stylu "review OpenTofu lock-file changes", a następnie zrebase'uj na to pracę nad funkcją. Mieszanie metadanych zależności z PR funkcji utrudnia przegląd obu zmian.

Opór interesariuszy. "Teraz działamy na forku" brzmi różnie w różnych organizacjach. Uczciwa odpowiedź jest taka, że OpenTofu w przypadkach opisanych w tym przewodniku pozostaje ogólnie kompatybilne pod względem konfiguracji z HCL w stylu Terraforma, więc zamiana jest zazwyczaj odwracalna. Gdyby OpenTofu zniknęło jutro, wiele zespołów mogłoby ponownie zainstalować Terraform, sprawdzić plik blokady i nadal używać tych samych .tf pliki. Najpierw zweryfikuj funkcje dodane po forku; to zastrzeżenie jest bardziej wiarygodne niż obiecywanie doskonałej zamienności.

Kiedy migracja jest naprawdę trudna

Ta prosta ścieżka nie dotyczy każdego środowiska Terraforma.

Migracja staje się znacznie trudniejsza, gdy:

• Stan jest duży (tysiące zasobów, dziesiątki obszarów roboczych) i znajduje się w HCP Terraform.
• Baza kodu głęboko wykorzystuje funkcje dostępne wyłącznie w HCP: polityki Sentinel powiązane z obszarami roboczymi, run triggers, dynamiczne poświadczenia dostawców zarządzane przez HCP. Terraform Stacks jest funkcją wyłącznie HCP i nie ma odpowiednika w OpenTofu, co wykracza poza zakres tego artykułu.
• Korporacyjny audyt lub framework zgodności wymienia "Terraform" jako oficjalne narzędzie IaC, co poza problemem technicznym stanowi też problem zakupowy i dokumentacyjny.
• Duża biblioteka modułów ma wewnętrzne ograniczenia wersji, które rozwiązywały się względem zachowania rejestru specyficznego dla Terraforma.

Nie każdy zespół powinien migrować. Bilans korzyści do kosztów ma sens tylko wtedy, gdy ograniczenia BSL faktycznie wpływają na twój przypadek użycia, gdy konkretna funkcja OpenTofu odblokowuje coś realnego, lub gdy plan rozwoju kontrolowany przez IBM jest realnym zmartwieniem dla twojej organizacji. Jeśli żadne z nich nie ma zastosowania, pozostanie przy Terraformie jest w pełni uzasadnioną decyzją.

Czy warto się przełączyć?

Nie ma tu jednej właściwej odpowiedzi. Kiedy rysuję drzewo decyzyjne dla zespołu, pojawiają się cztery typowe sytuacje, a właściwy ruch zależy od tego, w której z nich się znajdujesz.

Nowe wdrożenie IaC (greenfield). Zacznij od OpenTofu. Licencja to MPL 2.0, governance podlega Linux Foundation i CNCF, a projekt ma aktywne tempo wydawania wersji. Do jego wyróżników należy szyfrowanie stanu po stronie klienta, provider for_each, enabledoraz dynamiczny prevent_destroy. Nie musisz planować wokół tarcia związanego z BSL. To najmocniejsza rekomendacja w tym artykule.

Obecny użytkownik Terraforma, mały do średniego projekt. Przełącz się, jeśli spełni się którykolwiek z trzech warunków. Po pierwsze: sprzedajesz lub mógłbyś sprzedawać produkt, który mógłby wpaść w wyłączenie BSL "konkuruje z HashiCorp"; kalkulacja prawna jest czystsza przy MPL 2.0. Po drugie: potrzebujesz szyfrowania stanu po stronie klienta, provider for_each, enabled, lub dynamiczny prevent_destroy a obejście w Terraformie nie jest już warte utrzymywania. Po trzecie: wolisz zarządzanie wielostronne od planu rozwoju jednego dostawcy. Jeśli żadne z nich nie ma zastosowania, a Terraform działa sprawnie, zostań przy nim. Migracja jest odwracalna w wielu środowiskach, ale nie jest darmowa.

Intensywny użytkownik HCP Terraform. Traktuj to jako decyzję platformową, a nie automatycznie jako migrację backendu. OpenTofu może korzystać z kompatybilnych backendów zdalnych, ale zdalne wykonywanie specyficzne dla HCP, Sentinel, run triggers, dynamiczne poświadczenia i Stacks nadal wymagają oceny funkcja po funkcji. Jeśli te mechanizmy kontroli są kluczowe, najpierw przetestuj. Jeśli opuszczasz HCP z powodów licencyjnych, kosztowych lub governance, zaplanuj tę pracę jako migrację platformową.

Rozważasz Pulumi lub inną alternatywę bez HCL. OpenTofu to najbliższa ścieżka, jeśli chcesz zachować HCL i większość istniejących przepływów pracy. Pulumi to szersza platforma i wybór języka: TypeScript, Python, Go lub .NET sterujące interfejsami API chmury. Przejście tam może wymagać konwersji lub przepisania, więc oceń to osobno od zwykłej zamiany pliku binarnego Terraform na OpenTofu.

Warto bezpośrednio odnieść się jeszcze do jednej rzeczy: uzasadnionej krytyki, że OpenTofu jest częściowo zabezpieczeniem interesów dostawców SaaS. Wątek na Hacker News dotyczący zmiany BSL ujawnił obawę, że członkowie założyciele projektu to komercyjne platformy oparte na Terraformie z własną motywacją dotyczącą elastyczności licencyjnej. Traktuję tę obawę poważnie. Łagodzącym czynnikiem jest struktura governance, hosting w Linux Foundation, CNCF Sandbox, MPL 2.0 w każdym pliku, co czyni przyszłą zmianę licencji znacznie trudniejszą niż była zmiana licencji przez jednego dostawcę. Nie czyni tego niemożliwym. Czyni to jednak wystarczająco kosztownym, by stanowiło to realne zabezpieczenie.

Szybki werdykt. W przypadku nowych prac IaC w 2026 roku zacznij od OpenTofu. Jego licencja, governance, aktywny rozwój i zestaw funkcji czynią z niego mocny wybór domyślny. W przypadku istniejących wdrożeń Terraforma przełącz się, gdy zachodzi jeden z trzech powyższych warunków; w przeciwnym razie bilans korzyści do kosztów jest niewielki i pozostanie przy nim jest w porządku.

Gdy wybór narzędzia jest już jasny, kolejnym praktycznym pytaniem jest to, gdzie OpenTofu powinno działać. Ta decyzja wpływa na obsługę sekretów, koszty, powtarzalność oraz to, jaką kontrolę twój zespół ma nad środowiskiem wykonawczym.

Uruchamianie OpenTofu samodzielnie

OpenTofu to plik binarny CLI. To, gdzie go uruchamiasz, w dużej mierze decyduje o kosztach, bezpieczeństwie i o tym, co możesz z nim zrobić. Istnieją mniej więcej trzy rozsądne miejsca, w których można go umieścić.

Laptop lub maszyna deweloperska. W porządku dla jednorazowych planów, prototypowania i małych projektów osobistych. To słaby wybór domyślny dla współdzielonych przepływów produkcyjnych, chyba że zdalny stan, blokowanie i dyscyplina przeglądu są już wymuszone. Zespoły zwykle korzystają na kanonicznym środowisku wykonawczym zamiast polegania na tym, który laptop ostatnio uruchomił tofu apply.

Zarządzany runner CI (GitHub Actions, GitLab CI itp.). Typowa ścieżka. opentofu/setup-opentofu akcja jest bezpośrednim zamiennikiem dla hashicorp/setup-terraform. Sprawdza się to dobrze dla większości zespołów i projektów. Kompromisy: sekrety przechodzą przez usługę CI strony trzeciej, minuty w darmowym planie mogą się skończyć przy dużych operacjach na stanie, a środowisko runnera jest efemeryczne, co zwykle jest zaletą, ale czasem ograniczeniem. Zobacz GitHub vs GitLab jeśli nadal wybierasz między hostowanymi opcjami CI, a Best CI/CD Tools dla szerszego spojrzenia na temat.

Samodzielnie hostowany runner na VPS. Przydatne, gdy kompromisy zarządzanego CI przestają się sprawdzać: sekrety muszą pozostać poza usługą strony trzeciej, minuty CI stają się drogie, lub chcesz trwałej pamięci podręcznej dostawców. Konfiguracja jest prosta: VPS z Linuksem, plik binarny OpenTofu, agent GitHub Actions lub GitLab Runner oraz Docker do izolacji zadań. Zobacz Install Docker on VPS jeśli ta część jest dla ciebie nowa. Dla runnera małego zespołu rozsądnym punktem wyjścia jest 4 GB RAM, 2 vCPU i 60 GB NVMe; skaluj CPU, pamięć i przestrzeń dyskową dla większych planów i wyższej współbieżności.

Dla zespołów potrzebujących ściślejszej kontroli nad sekretami runnera, trwałej pamięci podręcznej dostawców lub przewidywalnych kosztów CI, samodzielnie hostowany runner na VPS może mieć sens. W takiej konfiguracji priorytetem powinien być dostęp root, szybkie magazynowanie NVMe, łatwe skalowanie oraz wystarczająca ilość CPU/RAM dla większych operacji planowania.

Cloudzy Linux VPS instancje pasują do tego wzorca samodzielnie hostowanego runnera dzięki dostępowi root, magazynowaniu NVMe i elastycznemu skalowaniu, dzięki czemu możesz zacząć od małej skali i rozbudowywać runnera w miarę wzrostu obciążeń OpenTofu.

Często zadawane pytania

Czy OpenTofu to to samo co Terraform?

Nie do końca. OpenTofu powstało jako fork Terraforma 1.5.x i pozostaje ogólnie kompatybilne pod względem konfiguracji z HCL w stylu Terraforma: te same .tf pliki, dostawcy oraz plan/apply workflow dla wielu projektów. Różnią się licencją i funkcjami dodanymi po forku. OpenTofu ma szyfrowanie stanu po stronie klienta, provider for_each, enabledoraz dynamiczny prevent_destroy; Terraform ma własne funkcje dodane po forku, w tym ephemeral resources.

Czy OpenTofu obsłuży wszystkich moich dostawców z Terraforma?

W przypadku głównych dostawców, takich jak AWS, GCP, Azure, Kubernetes i Helm, ogólnie tak. OpenTofu Registry podaje ponad 3900 dostawców na lipiec 2026 roku. tofu init może zaktualizować .terraform.lock.hcl metadane. W przypadku niszowych, specyficznych dla dostawcy lub nowo opublikowanych dostawców, sprawdź bezpośrednio dostępność i wsparcie wersji przed przełączeniem.

Czy OpenTofu samo mogłoby kiedyś zmienić licencję?

Przyszła zmiana licencji jest trudniejsza niż w przypadku Terraforma, ale nie niemożliwa. OpenTofu jest na licencji MPL 2.0, hostowane przez Linux Foundation i jest projektem sandboksowym CNCF od 23 kwietnia 2025 roku. Governance jest wielostronne, a licencja jest zatwierdzona przez OSI. Jednostronna zmiana licencji przez dowolnego pojedynczego założyciela byłaby sprzeczna zarówno ze statutem fundacji, jak i z istniejącymi wkładami na licencji MPL 2.0, które musiałyby zostać usunięte lub przepisane. Ta obawa jest uzasadniona; bariery strukturalne są realne.

Co przejęcie HashiCorp przez IBM oznacza dla przyszłości Terraforma?

IBM zakończyło przejęcie HashiCorp 27 lutego 2025 roku za 6,4 miliarda dolarów. Plan rozwoju Terraforma znajduje się teraz w ramach większego dostawcy korporacyjnego. Samo przejęcie nie przesądza o przyszłym licencjonowaniu ani kierunku produktu; oceniaj aktualne notatki o wydaniu, wytyczne licencyjne i zmiany produktów HCP, zamiast traktować własność jako prognozę.

Czy OpenTofu jest gotowe do produkcji w 2026 roku?

Tak. v1.12.5 to aktualna wersja serwisowa, projekt znajduje się w CNCF Sandbox, a Fidelity opisało wdrożenie produkcyjne w środowisku IaC z ponad 50 000 plikami stanu i czterema milionami zasobów. Gotowość do produkcji nie oznacza identyczności funkcji: zespoły polegające na funkcjach dostępnych wyłącznie w HCP, takich jak Terraform Stacks, nadal potrzebują osobnej decyzji o zgodności.