OpenTofu - przewodnik po open-source'owej alternatywie dla Terraform

10 sierpnia 2023 r. HashiCorp zmienił licencję Terraform, najpopularniejszego narzędzia do opisywania infrastruktury chmurowej kodem. Z otwartej licencji MPL przeszedł na Business Source License, która ogranicza wykorzystanie programu w produktach konkurencyjnych wobec firmy. Kilka tygodni później społeczność odpowiedziała forkiem. Tak powstał OpenTofu, dziś w pełni otwarta, open-source'owa alternatywa dla Terraform, rozwijana pod opieką Linux Foundation.

Przez pierwsze miesiące OpenTofu był po prostu kopią Terraform z inną nazwą. To się zmieniło. Oba narzędzia dostają dziś inne funkcje, mają inne plany rozwoju i innych właścicieli. Terraform od lutego 2025 r. należy do IBM.

Czym jest OpenTofu i skąd wzięła się alternatywa dla Terraform

Oba narzędzia realizują podejście Infrastructure as Code, czyli opisywania serwerów, baz danych, sieci i uprawnień w plikach tekstowych zamiast klikania w panelu dostawcy chmury. Taki opis można przechowywać w repozytorium, recenzować jak zwykły kod i odtworzyć całe środowisko jednym poleceniem. Narzędzie Terraform przez lata było w tej dziedzinie standardem. Obsługuje tysiące usług, od największych chmur po DNS, monitoring i systemy płatności, dzięki tzw. providerom, czyli wtyczkom tłumaczącym opis infrastruktury na wywołania API konkretnej usługi.

OpenTofu powstał z kodu Terraform w wersji sprzed zmiany licencji. Używa tego samego języka konfiguracji (HCL), tych samych providerów i tego samego formatu pliku stanu. Zamiast polecenia terraform wpisuje się tofu. Projekt jest rozwijany na licencji MPL 2.0, a w kwietniu 2025 r. został przyjęty do Cloud Native Computing Foundation, tej samej fundacji, która opiekuje się Kubernetesem.

Od zmiany licencji do wersji 1.12: jak projekty się rozeszły

Pierwsze stabilne wydanie OpenTofu, oznaczone numerem 1.6, pojawiło się w styczniu 2024 r. Było zgodne z Terraform 1.5 i miało jeden cel: pozwolić firmom przejść na otwartą wersję bez zmiany ani jednej linijki kodu.

Pierwszą funkcją, której Terraform nie miał, było szyfrowanie pliku stanu, wprowadzone wiosną 2024 r. w wersji 1.7. W tym samym czasie IBM ogłosił przejęcie HashiCorp za 6,4 mld dolarów, sfinalizowane w lutym 2025 r. Od tego momentu drogi rozchodzą się coraz wyraźniej. OpenTofu 1.10 z czerwca 2025 r. pozwala pobierać providery i moduły z rejestrów kontenerów (OCI), co ułatwia pracę w odizolowanych sieciach, i blokuje równoczesne zmiany stanu bez dodatkowej tabeli w DynamoDB. Wersja 1.11 z grudnia 2025 r. dodała wartości tymczasowe, które nie trafiają do pliku stanu, a 1.12 z maja 2026 r. pozwala różnie chronić zasoby przed usunięciem w zależności od środowiska.

Terraform rozwija się w swoim kierunku, coraz mocniej związanym z płatną platformą HCP Terraform. Kod napisany dla Terraform 1.5 nadal działa w obu narzędziach. Kod korzystający z najnowszych funkcji jednego z nich - już niekoniecznie.

Czy licencja Terraform dotyczy Twojej firmy

Najczęściej nie. Business Source License pozwala używać Terraform wewnątrz firmy do zarządzania własną infrastrukturą, także komercyjnie. Ograniczenie dotyczy firm, które oferują produkt konkurencyjny wobec HashiCorp, na przykład platformę do uruchamiania Terraform jako usługi. Dla typowego sklepu internetowego, SaaS-a czy systemu firmowego zmiana licencji nie oznacza obowiązku migracji. Różnicę między licencjami otwartymi a „źródłowo dostępnymi” dobrze pokazuje porównanie z licencjami open source, takimi jak BSD: w pełni otwarta licencja nie ogranicza, kto i w jakim celu może używać kodu. BSL takie ograniczenia wprowadza, a właściciel może je w przyszłości zmienić.

Dlatego powody, dla których firmy przechodzą na OpenTofu, rzadko są prawnicze. Liczy się niezależność od jednego dostawcy, którego polityka cenowa i produktowa zależy dziś od decyzji IBM, oraz funkcje, których Terraform nie oferuje.

Co OpenTofu robi inaczej niż Terraform

Oba narzędzia wyglądają w codziennej pracy niemal identycznie. Różnice ujawniają się w kilku konkretnych miejscach.

Funkcje dostępne tylko w OpenTofu

Najważniejsza to szyfrowanie stanu. Plik stanu to mapa całej infrastruktury: lista zasobów, ich identyfikatory i często dane wrażliwe, takie jak hasła do baz danych czy klucze dostępowe. W Terraform leży on w postaci jawnej, a jego bezpieczeństwo zależy od uprawnień do miejsca przechowywania. OpenTofu potrafi zaszyfrować stan i plany zmian po stronie klienta, kluczem z AWS KMS, Google Cloud KMS, OpenBao albo innego systemu zarządzania sekretami.

Do tego dochodzi obsługa rejestrów OCI, czyli możliwość trzymania providerów i modułów w tym samym rejestrze co obrazy kontenerów Docker. Dla firm pracujących w sieciach bez dostępu do internetu to realne uproszczenie. Mniejsze zmiany, jak argument enabled do warunkowego tworzenia zasobów, sprawiają, że kod infrastruktury jest czytelniejszy przy przeglądzie.

Czego OpenTofu nie zapewnia

OpenTofu to narzędzie wiersza poleceń, a nie platforma. Nie ma własnego odpowiednika HCP Terraform z panelem, historią uruchomień, politykami Sentinel i zarządzaniem uprawnieniami. Te funkcje zapewniają niezależne platformy, takie jak Spacelift, env0 czy Scalr, albo własny potok CI/CD. Brakuje też jednego producenta, który odpowiada za wsparcie. Firma, która potrzebuje umowy serwisowej z gwarantowanym czasem reakcji, może ją kupić u partnerów wspierających projekt, ale nie od „OpenTofu” jako firmy. Dla części działów zakupów to wystarczający powód, by zostać przy Terraform.

Jak przebiega migracja z Terraform do OpenTofu

W prostych projektach migracja jest zaskakująco nudna. Instaluje się OpenTofu, uruchamia inicjalizację w katalogu z istniejącym kodem i sprawdza, czy plan zmian jest pusty. Jeśli jest, infrastruktura została rozpoznana poprawnie i nic nie zostanie przebudowane. Oficjalny przewodnik migracji zaleca przy tym kopię zapasową stanu i test na małej zmianie, zanim OpenTofu przejmie pełną odpowiedzialność. Skalę możliwą do przeniesienia dobrze pokazuje Fidelity Investments. Firma opisała migrację ponad 50 tys. plików stanu i ponad 4 mln zasobów chmurowych obsługujących ponad 2 tys. aplikacji. Wniosek zespołu był prosty: najtrudniejszy nie jest kod, tylko wersjonowanie, potoki CI/CD i uzgodnienia między zespołami.

Bezpieczna migracja przebiega w kilku krokach:

1. Inwentaryzacja konfiguracji: wersje Terraform, używane providery, miejsce przechowywania stanu i zależności między projektami.
2. Kopia zapasowa stanu i przeniesienie jednego, najmniej ryzykownego środowiska, na przykład testowego.
3. Porównanie planów zmian w obu narzędziach. Każda różnica musi mieć wyjaśnienie, zanim przejdzie się dalej.
4. Aktualizacja potoków CI/CD i dokumentacji oraz stopniowe wycofanie starych wersji Terraform.
5. Dopiero na końcu włączenie funkcji dostępnych tylko w OpenTofu, takich jak szyfrowanie stanu.

Ostatni krok ma znaczenie. Po zaszyfrowaniu stanu powrót do Terraform wymaga odszyfrowania, więc warto go zrobić, gdy zespół jest pewien decyzji. Do tego momentu migrację da się cofnąć bez kosztów.

Kiedy zostać przy Terraform

Są sytuacje, w których zmiana narzędzia nie daje wiele. Jeśli firma intensywnie korzysta z HCP Terraform, ma w nim polityki, workspace'y i uprawnienia dla kilkudziesięciu osób, migracja oznacza też zmianę platformy. To projekt na miesiące, a nie na tydzień. Drugi przypadek to kod oparty na funkcjach dostępnych wyłącznie w nowszych wersjach Terraform i w HCP Terraform, na przykład Terraform Stacks. Tych konfiguracji nie da się po prostu uruchomić w OpenTofu i trzeba je przepisać. Bywa też, że migracja po prostu może poczekać. Jeśli infrastruktura działa, zespół jest mały, a licencja nie dotyczy działalności firmy, migracja może poczekać. Lepiej wtedy wpisać ją na listę spłaty długu technologicznego i wrócić do niej przy najbliższej większej zmianie w infrastrukturze, na przykład przy przejściu do nowego regionu chmury.

Nowe projekty to inna historia. Tu nie ma czego migrować, a start od razu w OpenTofu nic nie kosztuje. Jeśli zespół nie planuje korzystać z HCP Terraform, OpenTofu jest naszym zdaniem rozsądnym punktem startu.

OpenTofu w codziennej pracy zespołu

Samo narzędzie to połowa sukcesu. Infrastruktura opisana kodem daje korzyści dopiero wtedy, gdy zmiany przechodzą przez ten sam proces co kod aplikacji: pull request, automatyczny plan, przegląd i zatwierdzenie. W praktyce każda propozycja zmiany uruchamia w potoku CI/CD polecenie, które pokazuje, co dokładnie zmieni się w chmurze: które zasoby powstaną, które zostaną zmodyfikowane, a które usunięte. Recenzent widzi to przed wdrożeniem. Przypadkowe usunięcie produkcyjnej bazy danych przestaje być realnym scenariuszem.

Przy większej liczbie środowisk przydaje się podejście GitOps, w którym repozytorium jest jedynym źródłem prawdy o infrastrukturze, a ręczne zmiany w panelu dostawcy są wykrywane i zgłaszane. Na tym samym fundamencie opiera się Security as Code w DevOps: reguły bezpieczeństwa sprawdzane automatycznie przy każdej zmianie, a nie raz w roku podczas audytu. OpenTofu dobrze współpracuje z resztą narzędzi. Tworzy klaster, a za wdrażanie aplikacji w środowisku Kubernetes odpowiadają już narzędzia takie jak Helm czy Argo CD.

Z kolei konfigurację samych serwerów, gdy nie są kontenerami, wciąż często przejmuje Ansible jako narzędzie automatyzacji.

OpenTofu, Terraform czy Pulumi - jak wybrać

Wybór narzędzia do infrastruktury zależy mniej od samych funkcji, a bardziej od zespołu i tego, co już istnieje w firmie.

OpenTofu ma sens, gdy zespół zna HCL albo ma istniejący kod Terraform, zależy mu na otwartej licencji i nie potrzebuje platformy HCP. Terraform zostaje, gdy firma jest związana z ekosystemem HashiCorp lub IBM, korzysta z ich płatnych usług i ceni jedno źródło wsparcia. Pulumi jako alternatywa dla HCL ma sens tam, gdzie infrastrukturę piszą programiści aplikacji i wolą TypeScript lub Pythona od osobnego języka konfiguracji.

Każda z tych dróg jest rozsądna. Nierozsądne jest tylko jedno: infrastruktura, której nikt nie opisał kodem i którą zna jedna osoba. Porządkowanie takiej sytuacji to zadanie dla usług DevOps i architektury i warto je zacząć, zanim w ogóle pojawi się pytanie o wybór narzędzia.

Jeśli rozważasz migrację z Terraform albo chcesz uporządkować infrastrukturę swojego projektu, napisz do nas, a sprawdzimy, od czego warto zacząć.