IaC w 2026 — przegląd pola

Pamiętam swoje pierwsze terraform apply i ten dreszczyk, czy aby na pewno nie zaoram właśnie produkcji. Od tego czasu w Infrastructure-as-Code zmieniło się tyle, że rok 2026 zastał to pole zupełnie inne, niż je zostawił. W ciągu dwóch lat przeszło trzęsienie licencyjne, wchłonęło podejścia kwestionujące sam model „pisania infrastruktury osobno”, dorobiło się warstwy typowanej konfiguracji i — co najważniejsze dla tej serii — zaczęło wpuszczać do pętli agentów AI. To już nie wyścig „które narzędzie jest najlepsze”. To pole rozszczepiające się wzdłuż kilku osi naraz: podejścia, governance i autonomii.

Ten przegląd porządkuje tę mapę i czyta ją przez pryzmat platformy: nie „co modne”, lecz co daje się oprzeć na otwartym fundamencie, samoobsłudze i kontroli. Bo wybór silnika IaC w 2026 to nie tylko decyzja o składni — to decyzja o suwerenności, o tym, kto pisze infrastrukturę (człowiek czy agent) i kto za nią ręczy.

Trzęsienie licencyjne: kto teraz rządzi

Najgłośniejsza zmiana nie dotyczyła składni, lecz licencji. W sierpniu 2023 HashiCorp zmienił licencję Terraform z otwartej MPL 2.0 na Business Source License (BSL) — źródło widoczne, ale z ograniczeniami komercyjnymi. Reakcją był fork: we wrześniu 2023 grupa firm (Spacelift, env0, Gruntwork i inne) odbiła Terraform na ostatnim commicie MPL (v1.5.5), nazwała go OpenTofu i przekazała pod Linux Foundation.

Stawkę podniosło przejęcie: IBM ogłosił zakup HashiCorp (grudzień 2024, 6,4 mld USD), a transakcja zamknęła się 27 lutego 2025 — Terraform należy dziś do IBM i integruje się z Red Hat Ansible. Dla organizacji, które myślą o suwerenności i strategii wyjścia, to kluczowy sygnał: fundament infrastruktury wpadł pod jednego, eksterytorialnego właściciela.

Co istotne, fork dojrzał, a nie zwiądł. W 2026 OpenTofu ma 95%+ parytetu funkcji z Terraform (wspólne providery), a do tego rzeczy, których Terraform nie dostał: natywne szyfrowanie stanu end-to-end (Terraform wymaga do tego Vault albo zaszyfrowanego S3), provider-defined functions i szybsze wydania. W produkcji używają go m.in. Boeing, Capital One i AMD. Wniosek praktyczny: dla projektu greenfield bez długu w Terraform, OpenTofu jest dziś bezpiecznym domyślnym wyborem — otwarta licencja (MPL 2.0), governance Linux Foundation, brak ryzyka licencyjnego. To wprost zasada EIAC: wybieraj silnik otwarty i fundacyjny, nie zakładnika jednego vendora.

Cztery obozy podejścia

Pod warstwą licencji pole dzieli się na cztery sposoby myślenia o tym, czym w ogóle jest opis infrastruktury.

Obóz	Reprezentanci	Idea	Cena wyboru
Deklaratywny HCL	OpenTofu, Terraform	Domeno-specyficzny język, plan/apply, stan	HCL bywa ciasny przy logice; stan do pilnowania
Pełny język	Pulumi, AWS CDK, SST	Infrastruktura w TS/Go/Python — pętle, typy, testy	Większa moc = większa szansa na nadmiar sprytu
Control plane	Crossplane	Infrastruktura jako API Kubernetes, ciągły reconcile	Wymaga K8s i zmiany modelu myślenia
Infrastructure-from-Code	Encore, SST, Winglang, Nitric	Infrastruktura wywnioskowana z kodu aplikacji	Abstrakcja przecieka; ryzyko lock-in

Deklaratywny HCL to wciąż centrum grawitacji — i po forku pozostaje najbezpieczniejszym wyborem, o ile sięgasz po OpenTofu. Pełny język (Pulumi) kusi zespoły, które chcą pisać infrastrukturę tak jak aplikacje: z pętlami, typami i testami jednostkowymi. Pulumi dołożył do tego ESC (Environments, Secrets, Configuration) — warstwę config-as-code z dynamicznymi, krótkożyciowymi poświadczeniami przez OIDC, działającą też niezależnie od samego Pulumi IaC.

Control plane to najgłębsza zmiana modelu. Crossplane — projekt CNCF, który osiągnął poziom „graduated” w listopadzie 2025 — zamienia infrastrukturę w API Kubernetes i nieustannie uzgadnia stan rzeczywisty z zadeklarowanym. Wersja 2.0 (sierpień 2025) uprościła model (zasoby namespaced domyślnie, composition functions zamiast patch-and-transform). Kluczowy cytat z ich pozycjonowania jest dla nas znaczący: control plane pozwala „zarówno ludziom, jak i inteligentnym agentom bezpiecznie zamawiać i zarządzać środowiskami przez API” — wrócimy do tego przy platformie agentowej.

Czwarty obóz: Infrastructure-from-Code

Najbardziej kwestionujące status quo jest podejście infrastructure-from-code (IfC), wokół którego toczy się szczery spór „czy IaC umarło?”. Teza IfC: skoro kod aplikacji i kod infrastruktury i tak muszą być zsynchronizowane, to po co pisać je osobno? Niech opis zasobów będzie wywnioskowany z kodu aplikacji.

Obóz nie jest jednorodny — i warto rozróżnić jego odmiany, bo różnią się ceną:

• Encore idzie najdalej: infrastruktura deklarowana wprost w kodzie aplikacji, wyprowadzana automatycznie, bez plików stanu i cyklu plan/apply.
• SST to superzbiór AWS CDK skupiony na świetnym DX dla serverless na AWS.
• Winglang stawia tezę, że istniejące języki nie wystarczają do opisu chmury (rozróżnia kod „preflight” wykonywany przy wdrożeniu i „inflight” w runtime); dziś oferuje też SDK dla TypeScript.
• Nitric celowo uzupełnia IaC: generuje specyfikację wymagań z kodu aplikacji i przekazuje ją pluginom, które produkują konfigurację Terraform/innego silnika — utrzymując IaC w synchronizacji z aplikacją.

Uczciwa ocena: IfC nie jest „następcą”, który zabije IaC, tylko inną odpowiedzią na realny problem synchronizacji. Płaci za wygodę dwiema walutami: przeciekającą abstrakcją (gdy coś się psuje pod spodem, i tak musisz zejść do warstwy, którą ukryto) i ryzykiem lock-in (framework dyktuje model). Dlatego porównanie dwóch flagowców — SST kontra Encore — opisaliśmy osobno. Reguła kciuka: IfC świeci przy greenfield i serverless, gdzie tempo zmian aplikacji jest wysokie; przy złożonej, długowiecznej infrastrukturze wciąż wygrywa jawny IaC.

Warstwa pod spodem: typowana konfiguracja

Równolegle dojrzała warstwa, o której łatwo zapomnieć: języki konfiguracji zastępujące surowy YAML/JSON tam, gdzie ten przestaje się skalować. Zamiast kopiować bloki i modlić się o spójność, opisujesz konfigurację z typami, walidacją i funkcjami.

Trzech głównych graczy różni się filozofią:

• KCL — projekt CNCF (Sandbox), język ograniczeń, statycznie kompilowany, szybki przy dużej skali; szczególnie mocny do budowania composition w Crossplane.
• CUE — silny system typów i ograniczeń sprawdzanych w runtime; bez oficjalnego wsparcia IDE.
• Pkl — od Apple, ergonomiczny (klasy, funkcje), z dojrzałym wsparciem edytorów i bogatą walidacją typów.

To nie konkurenci IaC, lecz warstwa, która karmi go czystymi, walidowanymi danymi — szczególnie cenna, gdy te dane ma generować lub czytać agent. W EIAC ten sam impuls, co przy tokenach designu: zamknij wartości w typowanym, walidowalnym kształcie, zamiast w luźnym tekście.

Warstwa nad spodem: automatyzacja (TACOS)

Sam silnik IaC nie rozwiązuje pracy zespołowej: blokowania stanu, wykrywania driftu, RBAC, prywatnych rejestrów, egzekwowania polityk. Tę lukę wypełnia kategoria TACOS (Terraform/OpenTofu Automation and Collaboration Software):

• Atlantis — otwarty pionier wzorca „plan/apply z komentarza w PR”; trzeba samemu złożyć płaszczyznę zarządzania.
• Spacelift, env0 (z naciskiem na FinOps), Scalr (drop-in Terraform Cloud) — komercyjne platformy z drift detection, granularnym RBAC i GitOps; Terramate to ich lekka, open-source alternatywa (stacki + change detection).
• OpenTaco (dawniej Digger) — orkiestruje przebiegi Terraform/OpenTofu wewnątrz Twojego CI (np. Gitea/GitHub Actions), zamiast uruchamiać własny compute, z self-hostowanym backendem stanu.

Dla platformy suwerennej wybór TACOS to znów decyzja o kontroli: model „w Twoim CI, z Twoim stanem” (Digger) trzyma całość po Twojej stronie, zgodnie z exit-by-design. Drift detection — wykrywanie, że stan rzeczywisty rozjechał się z kodem — to dziś funkcja oczekiwana, nie luksus; a w 2026 przestaje być „tylko wykrywaniem”.

AI wchodzi w pętlę: IaC w platformie agentowej

Tu pole zmienia się najszybciej. Trzy zjawiska schodzą się w jedno:

1. Generacja — AI pisze kod aplikacji szybciej, niż zespoły piszą do niego infrastrukturę. Wąskim gardłem staje się IaC, więc to ono jest następne do zautomatyzowania.
2. Remediacja driftu — agentowa naprawa driftu przestała być eksperymentem; jest operacyjna. Narzędzia przechodzą od „tylko wykrywam” do „samo koryguję”: cofają nieautoryzowane zmiany z konsoli i utrzymują stan pożądany.
3. Control plane jako interfejs dla agentów — Crossplane i pokrewne dają agentom bezpieczny, deklaratywny punkt zamawiania zasobów przez API.

Wzorzec, który się wyłania, jest dokładnie tym z czterech poziomów agentowego wytwarzania: guardrails konfigurowane per workflow — pełna autonomia dla operacji dobrze zrozumianych (right-sizing zasobów nieprodukcyjnych, naprawa znanego driftu), a człowiek w pętli przy zmianach wrażliwych. Tego nie da się zrobić bezpiecznie bez bramki: policy-as-code jest tym punktem decyzyjnym, przez który musi przejść każdy apply — niezależnie, czy zainicjował go człowiek, czy model. To jest deterministyczny szkielet ADP zastosowany do infrastruktury: nie ufamy agentowi „że nie zepsuje”, tylko zamykamy go w polityce i przeglądzie planu.

# OpenTofu: ten sam plan przechodzi przez bramkę polityki w CI,
# zanim ktokolwiek (człowiek czy agent) zrobi apply
resource "aws_s3_bucket" "data" {
  bucket = "eiac-sovereign-eu"
}

resource "aws_s3_bucket_server_side_encryption_configuration" "data" {
  bucket = aws_s3_bucket.data.id           # wymagane przez politykę:
  rule {                                    # conftest/checkov odrzuci plan
    apply_server_side_encryption_by_default { sse_algorithm = "aws:kms" }
  }
}

Jak wybrać

Nie ma jednego zwycięzcy — jest dopasowanie do kontekstu. Cztery typowe sytuacje:

• Greenfield, brak długu w Terraform → OpenTofu. Otwarta licencja, szyfrowanie stanu, governance LF. Domyślny wybór „bez żalu”.
• Zespół chce pisać infrastrukturę jak aplikację (typy, testy) → Pulumi + ESC; pełny język w cenie większej odpowiedzialności za dyscyplinę.
• Budujesz platformę z samoobsługą i chcesz, by zamawiali z niej też agenci → Crossplane jako control plane, ewentualnie KCL do composition.
• Greenfield serverless, tempo aplikacji > tempo infrastruktury → IfC (Encore/SST), ze świadomością ceny abstrakcji i lock-in.

A ponad tymi wyborami — dwie stałe, niezależne od obozu: trzymaj się otwartego, fundacyjnego silnika (osłona przed ryzykiem licencyjnym i eksterytorialnym) oraz postaw bramkę policy-as-code (jedyny sposób, by wpuścić agentów do pętli bez utraty kontroli). Migracja Terraform → OpenTofu jest dziś nisko-ryzykowna dzięki parytetowi; wejście w agentowy IaC bez polityki — wręcz przeciwnie.

Podsumowanie

IaC w 2026 to nie pojedynczy wyścig narzędzi, lecz pole rozpięte na trzech osiach: podejście (HCL, język, control plane, IfC), governance (BSL pod IBM vs Linux Foundation za OpenTofu) i autonomia (od ręcznego kodu po agentową remediację driftu). Pod silnikami dojrzała warstwa typowanej konfiguracji (KCL/CUE/Pkl), nad nimi — automatyzacja TACOS, a ponad wszystkim wchodzą agenci. Dla platformy, która ma być otwarta, suwerenna i gotowa na AI, odpowiedź EIAC jest spójna z resztą serii: wybierz otwarty, fundacyjny silnik, opisz wszystko jako kod i zamknij każdy apply w bramce policy-as-code — wtedy każda z tych osi pozostaje wyborem, a nie pułapką. A jeśli masz stary stack w Terraform i zachodzisz w głowę, czy migrować — migruj na OpenTofu. Parytet jest, ryzyko małe, a spokój duży. :)