Teza
W 2026 nie wybierasz „narzędzia IaC", lecz pozycję na trzech osiach naraz: podejście (deklaratywny HCL, pełny język, control plane, czy infrastructure-from-code), governance (BSL pod jednym vendorem vs Linux Foundation), oraz autonomia (kod pisany ręcznie, generowany przez agenta, czy reconcile'owany automatycznie). Otwartość i policy-as-code to nie dodatki — to warunek, by pozostałe osie nie zamieniły się w pułapkę.
## 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](https://mariadb.com/bsl11/) (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](/katalog/opentofu) i przekazała pod [Linux Foundation](https://www.linuxfoundation.org/).
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](/blog/suwerenny-idp-exit-by-design), to kluczowy sygnał: fundament infrastruktury wpadł pod jednego, eksterytorialnego właściciela.
Co istotne, fork dojrzał, a nie zwiądł. W 2026 [OpenTofu](/katalog/opentofu) ma 95%+ parytetu funkcji z [Terraform](/katalog/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](/katalog/opentofu), [Terraform](/katalog/terraform) | Domeno-specyficzny język, `plan`/`apply`, stan | HCL bywa ciasny przy logice; stan do pilnowania |
| **Pełny język** | [Pulumi](/katalog/pulumi), AWS CDK, [SST](/katalog/sst) | Infrastruktura w TS/Go/Python — pętle, typy, testy | Większa moc = większa szansa na nadmiar sprytu |
| **Control plane** | [Crossplane](/katalog/crossplane) | Infrastruktura jako API Kubernetes, ciągły reconcile | Wymaga K8s i zmiany modelu myślenia |
| **Infrastructure-from-Code** | [Encore](/katalog/encore), [SST](/katalog/sst), [Winglang](/katalog/winglang), [Nitric](/katalog/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](/katalog/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](https://www.pulumi.com/docs/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](/katalog/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](https://encore.dev/) idzie najdalej: infrastruktura deklarowana wprost w kodzie aplikacji, wyprowadzana automatycznie, bez plików stanu i cyklu plan/apply.
- [SST](/katalog/sst) to superzbiór AWS CDK skupiony na świetnym DX dla serverless na AWS.
- [Winglang](/katalog/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](/katalog/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](/blog/sst-vs-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](https://www.kcl-lang.io/) — projekt CNCF (Sandbox), język ograniczeń, statycznie kompilowany, szybki przy dużej skali; szczególnie mocny do budowania composition w [Crossplane](/katalog/crossplane).
- [CUE](https://cuelang.org/) — silny system typów i ograniczeń sprawdzanych w runtime; bez oficjalnego wsparcia IDE.
- [Pkl](https://pkl-lang.org/) — 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](/blog/design-as-code-tokeny-od-zera): 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](https://www.runatlantis.io/) — otwarty pionier wzorca „plan/apply z komentarza w PR"; trzeba samemu złożyć płaszczyznę zarządzania.
- [Spacelift](/katalog/spacelift), [env0](/katalog/env0) (z naciskiem na FinOps), [Scalr](/katalog/scalr) (drop-in Terraform Cloud) — komercyjne platformy z drift detection, granularnym RBAC i GitOps; [Terramate](/katalog/terramate) to ich lekka, open-source alternatywa (stacki + change detection).
- [OpenTaco](/katalog/digger) (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](/blog/suwerenny-idp-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](/katalog/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](/blog/cztery-poziomy-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](/blog/policy-as-code-dla-zespolow) 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](/blog/deterministyczny-szkielet-adp) zastosowany do infrastruktury: nie ufamy agentowi „że nie zepsuje", tylko zamykamy go w polityce i przeglądzie planu.