# eiac.dev — pełna treść (Everything Is A Code)

> Pismo i katalog o zarządzaniu z kodu. Poniżej pełna treść artykułów (markdown) oraz opisy narzędzi z katalogu. Źródło: https://eiac.dev. Indeks: https://eiac.dev/llms.txt

======== ARTYKUŁY ========


# Aplikacje z kodu: SST vs Encore

URL: https://eiac.dev/blog/sst-vs-encore
Filar: App-as-Code
Data: 2026-05-15
Tagi: sst, encore, aws, typescript, app-as-code
Skrót: Dwa podejścia do App-as-Code: elastyczny framework IaC (SST) kontra konwencja z infrastrukturą wywiedzioną z kodu (Encore). Model, przykłady, wady i zalety.

Lubię takie porównania, bo dwa narzędzia obiecują dokładnie to samo, a pod maską są zupełnie inne. Obie platformy mówią: opisujesz aplikację w kodzie, a one ogarniają infrastrukturę pod spodem. Różni je jednak coś fundamentalnego — _skąd_ bierze się wiedza o tym, jaka infrastruktura jest potrzebna. [SST](/katalog/sst) każe Ci ją **zadeklarować** (elastycznie, jak w klasycznym IaC), [Encore](/katalog/encore) **wywodzi** ją z Twojego kodu aplikacji (przez analizę statyczną). To pozornie drobne rozróżnienie pociąga za sobą całą resztę: język, lock-in, sposób pracy lokalnej i to, ile decyzji musisz podjąć.

<div class="callout">
<strong>Oś sporu</strong>
<p>SST = <em>konfiguracja</em>: ty komponujesz zasoby z bloczków IaC. Encore = <em>konwencja</em>: framework czyta kod i sam dokłada infrastrukturę.</p>
</div>

## Czym jest SST

SST to framework do budowy i wdrażania pełnych aplikacji (frontend + backend + infrastruktura) — głównie na AWS. W wersji 3 jego silnikiem jest Pulumi z providerami Terraform, więc pod maską masz pełną moc klasycznego IaC: setki providerów i zasobów. Na wierzchu dostajesz wysokopoziomowe **komponenty** (`sst.aws.Function`, `sst.aws.Bucket`, `sst.aws.Astro` itd.), które ukrywają boilerplate, oraz mechanizm `link`, który automatycznie przekazuje uprawnienia i zmienne między zasobami.

Aplikację opisujesz w `sst.config.ts` — zwykłym TypeScript, z pętlami, warunkami i pakietami:

```ts
// sst.config.ts
export default $config({
  app: () => ({ name: "eiac", home: "aws" }),
  async run() {
    const bucket = new sst.aws.Bucket("Assets");

    const api = new sst.aws.Function("Api", {
      handler: "src/api.handler",
      url: true,
      link: [bucket], // nadaje funkcji dostęp do bucketa (IAM + env)
    });

    new sst.aws.Astro("Web", { link: [api] });

    return { api: api.url };
  },
});
```

Sygnaturą SST jest tryb `sst dev` — uruchamia lokalną pętlę developerską, w której kod funkcji działa na Twojej maszynie, ale jest wpięty w _prawdziwe_ zasoby w chmurze (tzw. Live Lambda). Dostajesz natychmiastowy feedback bez ciągłego deployu.

```bash
npx sst dev      # lokalny dev wpięty w realne zasoby w chmurze
npx sst deploy --stage production
```

Kluczowe cechy modelu SST:

- **Pełen IaC pod spodem** — przez Pulumi/Terraform sięgniesz po dowolny zasób (kolejki, bazy, DNS, Cloudflare), nie tylko gotowe komponenty.
- **Frontend i backend razem** — komponenty dla Next/Astro/React Router wdrażasz obok API w jednym repo.
- **`link` zamiast ręcznego IAM** — relacje między zasobami zamiast ręcznego klejenia uprawnień i zmiennych.
- **Stan i etapy (stages)** — odseparowane środowiska (`--stage`), stan trzymany jak w Pulumi.

## Czym jest Encore

Encore odwraca kierunek. Zamiast deklarować infrastrukturę, **deklarujesz elementy aplikacji** — serwisy, endpointy, bazy, kolejki, crony — jako konstrukcje w kodzie (TypeScript lub Go). Encore analizuje ten kod statycznie, buduje graf aplikacji i sam provisionuje potrzebne zasoby: lokalnie, a po wdrożeniu w chmurze. Infrastruktury nie opisujesz osobno — ona „wynika" z tego, czego użyłeś.

```ts
// api.ts — serwis, endpoint i baza wywiedzione z kodu
import { api } from "encore.dev/api";
import { SQLDatabase } from "encore.dev/storage/sqldb";

const db = new SQLDatabase("catalog", { migrations: "./migrations" });

export const getTool = api(
  { method: "GET", path: "/tools/:id", expose: true },
  async ({ id }: { id: string }) => {
    const row = await db.queryRow`SELECT name FROM tools WHERE id = ${id}`;
    return { tool: row?.name };
  },
);
```

Z deklaracji `new SQLDatabase(...)` Encore wie, że potrzebna jest baza — i tworzy ją sam (lokalnie w kontenerze, w chmurze jako zarządzaną instancję). Wywołania między serwisami są typowane: importujesz funkcję innego serwisu i wołasz ją jak zwykłą, a Encore zamienia to w wywołanie sieciowe z zachowaniem typów.

Drugą sygnaturą Encore jest lokalny dashboard: `encore run` startuje aplikację z **rozproszonym tracingiem, eksploratorem API i automatyczną dokumentacją** — bez konfiguracji.

```bash
encore run        # lokalnie: dashboard, tracing, API explorer
encore deploy     # wdrożenie (Encore Cloud) ...
encore build docker eiac:latest   # ... albo własny obraz do self-hostingu
```

Wdrożenie ma dwie drogi: **Encore Cloud** automatycznie provisionuje aplikację na Twoim koncie AWS/GCP (i daje CI/CD, środowiska, podgląd), albo budujesz samodzielny obraz Dockera (`encore build`) i uruchamiasz go gdziekolwiek, np. na [Kubernetes](/katalog/kubernetes).

Kluczowe cechy modelu Encore:

- **Infrastruktura z kodu** — brak osobnego IaC; zasoby wynikają z użytych prymitywów.
- **Konwencja zamiast konfiguracji** — mniej „kleju", więcej narzuconej struktury.
- **Wbudowana obserwowalność** — tracing, metryki, dokumentacja API od ręki.
- **Bezpieczne wywołania między serwisami** — typowane, sprawdzane w czasie kompilacji.

## Filozofia: konfiguracja kontra konwencja

To jest sedno różnicy. W SST infrastruktura jest **jawna i programowalna** — masz nad nią pełną kontrolę, ale też pełną odpowiedzialność: to Ty decydujesz, jaki zasób powołać i jak go połączyć. W Encore infrastruktura jest **domniemana** — framework wie, czego potrzebujesz, bo przeczytał Twój kod; płacisz za to dopasowaniem się do jego modelu.

Z tego wypływają wszystkie praktyczne konsekwencje: elastyczność kontra prostota, brak lock-inu na runtime kontra wbudowane „baterie", krzywa wejścia po stronie infrastruktury kontra krzywa wejścia po stronie konwencji frameworka.

## Te same zadania, dwa style

Spójrz na to samo zadanie — API z dostępem do magazynu danych — w obu narzędziach.

W **SST** najpierw deklarujesz zasób (`Bucket`), potem jawnie łączysz go z funkcją (`link`), a uprawnienia IAM i zmienne środowiskowe wygeneruje framework:

```ts
const bucket = new sst.aws.Bucket("Assets");
new sst.aws.Function("Api", { handler: "src/api.handler", link: [bucket] });
```

W **Encore** po prostu używasz prymitywu w kodzie — sama jego obecność „zamawia" infrastrukturę:

```ts
const bucket = new Bucket("assets", { public: false });
// użycie bucket.upload(...) w endpointcie wystarcza, by Encore go zapewnił
```

Różnica nie jest składniowa, lecz koncepcyjna: w SST infrastruktura to osobny, jawny obiekt; w Encore to efekt uboczny użycia API.

## Różnice w kluczowych wymiarach

| Wymiar               | SST                                    | Encore                                          |
| -------------------- | -------------------------------------- | ----------------------------------------------- |
| Model infrastruktury | deklarowana jawnie (komponenty)        | wywiedziona z kodu (analiza statyczna)          |
| Pod maską            | Pulumi + providerzy Terraform          | własny runtime + generowane IaC                 |
| Języki               | TypeScript/JavaScript                  | TypeScript i Go                                 |
| Chmura               | AWS-first (też Cloudflare i inne)      | AWS/GCP (Encore Cloud) lub własny obraz         |
| Frontend             | tak (Next/Astro/React…)                | nie (backend-first)                             |
| Lokalny DX           | `sst dev` (Live Lambda, realne zasoby) | `encore run` (dashboard, tracing, API explorer) |
| Obserwowalność       | dokładasz sam                          | wbudowana                                       |
| Elastyczność infry   | bardzo wysoka (cały IaC)               | ograniczona do modelu frameworka                |
| Lock-in              | na AWS/komponenty, nie na runtime      | na model i runtime Encore                       |
| Wyjście awaryjne     | naturalne (dropniesz do surowego IaC)  | węższe (poza modelem trudniej)                  |

## Wady i zalety

### SST

**Zalety**

- Pełna moc IaC — sięgniesz po dowolny zasób przez Pulumi/Terraform, nie tylko gotowce.
- Frontend + backend + infrastruktura w jednym repo i jednym wdrożeniu.
- `link` realnie redukuje boilerplate IAM i konfiguracji.
- Brak narzuconego runtime — Twój kod to zwykłe funkcje; mniejszy lock-in na sposób pisania.
- Świetny lokalny feedback (Live Lambda).

**Wady**

- AWS-centryczny — najlepiej działa na AWS; poza nim wsparcie jest węższe.
- Więcej decyzji i wiedzy o infrastrukturze po Twojej stronie.
- Trzeba zarządzać stanem i etapami (jak w Pulumi).
- Obserwowalność i konwencje musisz sobie poskładać sam.

### Encore

**Zalety**

- Minimum boilerplate — infrastruktura wynika z kodu, bez osobnego IaC.
- Wbudowana obserwowalność (tracing, metryki, dokumentacja API) od pierwszej minuty.
- Typowane, bezpieczne wywołania między serwisami.
- Spójna struktura w zespole dzięki konwencji.
- Elastyczne wdrożenie: Encore Cloud albo własny obraz Dockera.

**Wady**

- Lock-in na model i runtime Encore — wychodzisz poza schemat z trudem.
- Ograniczona elastyczność dla nietypowej infrastruktury.
- Tylko Go i TypeScript.
- Mniejszy ekosystem i społeczność niż wokół Pulumi/Terraform.
- „Magia" analizy statycznej bywa trudniejsza do debugowania, gdy coś nie zadziała.

## Kiedy co wybrać

- **Wybierz SST**, gdy potrzebujesz pełnej kontroli nad infrastrukturą AWS, chcesz wdrażać frontend razem z backendem albo sięgać po zasoby spoza „happy path" (kolejki, nietypowe usługi, multi-provider). Cena: więcej decyzji i wiedzy o IaC.
- **Wybierz Encore**, gdy budujesz backend/mikroserwisy i zależy Ci na maksymalnej prostocie, wbudowanej obserwowalności i szybkim starcie — a akceptujesz związanie z modelem frameworka. Cena: mniej elastyczności i lock-in na runtime.

Dobry papierek lakmusowy: jeśli najwięcej czasu spędzasz na _infrastrukturze_ i chcesz nią rządzić — SST. Jeśli najwięcej czasu spędzasz na _logice biznesowej_ i chcesz, żeby infrastruktura „po prostu była" — Encore.

## Podsumowanie

SST i Encore rozwiązują ten sam problem z dwóch przeciwnych stron. SST to elastyczny framework IaC z wysokopoziomowymi komponentami: dużo mocy, dużo kontroli, AWS w centrum. Encore to opinionowany framework backendowy, który infrastrukturę wywodzi z kodu i dorzuca obserwowalność: mało boilerplate'u, szybki start, w zamian za życie wewnątrz jego modelu.

Wybór sprowadza się do jednego pytania: czy chcesz **rządzić** infrastrukturą, czy chcesz o niej **zapomnieć**. Obie odpowiedzi są poprawne — pod warunkiem, że świadomie zaakceptujesz ich konsekwencje. U mnie? Zależy od projektu: do szybkiego backendu sięgam po Encore, do czegoś, co muszę wyrzeźbić po swojemu — po SST. Weź oba na warsztat na jednym weekendowym projekcie, różnicę poczujesz w pięć minut. :)

---


# IaC w 2026 — przegląd pola

URL: https://eiac.dev/blog/iac-2026-przeglad
Filar: Infrastructure-as-Code
Data: 2026-05-07
Tagi: terraform, opentofu, pulumi, crossplane, iac, platform-engineering, adp
Skrót: Po trzęsieniu licencyjnym IaC rozszczepia się na trzech osiach: podejście, governance i autonomia. Cztery obozy narzędzi, warstwa typowanej konfiguracji, automatyzacja TACOS i wejście agentów.

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](/blog/platform-engineering-normalizacja-pracy): 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.

<div class="callout">
<strong>Teza</strong>
<p>W 2026 nie wybierasz „narzędzia IaC", lecz pozycję na trzech osiach naraz: <em>podejście</em> (deklaratywny HCL, pełny język, control plane, czy infrastructure-from-code), <em>governance</em> (BSL pod jednym vendorem vs Linux Foundation), oraz <em>autonomia</em> (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ę.</p>
</div>

## 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.

<figure>
<svg viewBox="0 0 640 300" role="img" aria-label="Mapa pola IaC 2026 jako stos czterech warstw: konfiguracja typowana (KCL, CUE, Pkl), silnik IaC w czterech obozach (HCL, pełny język, control plane, infrastructure-from-code), automatyzacja TACOS i GitOps, a nad całością warstwa agentowa z bramką policy-as-code. Z prawej strony pionowa oś governance od BSL do Linux Foundation.">
  <g font-family="'Space Grotesk', system-ui, sans-serif" text-anchor="middle">
    <rect x="20" y="34" width="560" height="48" rx="6" fill="none" stroke="var(--color-rust)" stroke-width="1.5" stroke-dasharray="5 3"/>
    <text x="300" y="56" fill="var(--color-rust)" font-size="13">Warstwa agentowa — bramka policy-as-code</text>
    <text x="300" y="73" fill="var(--color-muted)" font-size="10" font-family="'Space Mono', monospace">generacja · remediacja driftu · człowiek w pętli przy ryzyku</text>
    <rect x="20" y="98" width="560" height="44" rx="6" fill="none" stroke="currentColor" stroke-width="1.5"/>
    <text x="300" y="118" fill="currentColor" font-size="13">Automatyzacja: TACOS · GitOps</text>
    <text x="300" y="134" fill="var(--color-muted)" font-size="10" font-family="'Space Mono', monospace">Atlantis · Spacelift · env0 · Scalr · OpenTaco · Terramate</text>
    <rect x="20" y="158" width="560" height="52" rx="6" fill="none" stroke="currentColor" stroke-width="1.5"/>
    <text x="300" y="180" fill="currentColor" font-size="13">Silnik IaC — cztery obozy</text>
    <text x="300" y="197" fill="var(--color-muted)" font-size="10" font-family="'Space Mono', monospace">HCL · pełny język · control plane · infrastructure-from-code</text>
    <rect x="20" y="226" width="560" height="44" rx="6" fill="none" stroke="currentColor" stroke-width="1.5"/>
    <text x="300" y="252" fill="currentColor" font-size="13">Konfiguracja typowana: KCL · CUE · Pkl</text>
  </g>
  <g font-family="'Space Mono', monospace" font-size="11" text-anchor="middle">
    <text x="608" y="44" fill="var(--color-muted)">BSL</text>
    <line x1="608" y1="54" x2="608" y2="250" stroke="var(--color-muted)" stroke-width="1.5"/>
    <path d="M608 250 l-4 -7 h8 z" fill="var(--color-rust)"/>
    <text x="608" y="266" fill="var(--color-rust)">LF</text>
  </g>
</svg>
<figcaption>Mapa pola IaC 2026: cztery warstwy (konfiguracja → silnik → automatyzacja → agent), a z prawej oś governance — od zamkniętej licencji BSL po otwarty Linux Foundation.</figcaption>
</figure>

```hcl
# 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](/katalog/opentofu). Otwarta licencja, szyfrowanie stanu, governance LF. Domyślny wybór „bez żalu".
- **Zespół chce pisać infrastrukturę jak aplikację (typy, testy)** → [Pulumi](/katalog/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](/katalog/crossplane) jako control plane, ewentualnie [KCL](https://www.kcl-lang.io/) do composition.
- **Greenfield serverless, tempo aplikacji > tempo infrastruktury** → IfC ([Encore](https://encore.dev/)/[SST](/katalog/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. :)

---


# Security Plane: sekrety, tożsamość i policy-as-code

URL: https://eiac.dev/blog/security-plane-sekrety-tozsamosc-policy
Filar: Security-as-Code
Data: 2026-04-30
Tagi: security, secrets, identity, policy-as-code, agents
Skrót: Trzy filary Security Plane — tożsamość, sekrety i policy-as-code — działają razem, self-hostowane i opisane jako kod, spełniając jednocześnie wymóg suwerenności i audytowalnej autonomii.

Security Plane przewija się przez całą serię — w [Suwerennym IDP](/blog/suwerenny-idp-exit-by-design) jako jedna z pięciu płaszczyzn, w [Deterministycznym szkielecie](/blog/deterministyczny-szkielet-adp) jako warunek bezpiecznej autonomii agentów. Tu poświęcam jej całą uwagę, bo to warstwa, na której najłatwiej się przewrócić. Teza spaja oba konteksty: w platformie suwerennej i agentowej **root of trust musi być lokalny i deklaratywny** — tożsamość, sekrety i polityki pod kontrolą organizacji, opisane jako kod, a nie rozsiane po konsolach dostawców.

<div class="callout">
<strong>Teza</strong>
<p>Bezpieczeństwa nie da się „dokleić" na końcu. To płaszczyzna przecinająca wszystkie inne: jeśli tożsamość, sekrety i polityki są u obcego dostawcy lub poza kodem, ani suwerenność, ani audytowalna autonomia agentów nie są możliwe.</p>
</div>

## Tożsamość: niezależny broker zamiast natywnego IAM

Poleganie na natywnym IAM dostawcy chmury (np. AWS IAM) przywiązuje perymetr tożsamości do tego konkretnego vendora — i łamie suwerenność. Wzorzec to **niezależny broker tożsamości**, self-hostowany, integrujący istniejące źródła logowania.

Dla brokera federującego ([OIDC](https://openid.net/developers/how-connect-works/) przed wieloma źródłami: [LDAP](https://datatracker.ietf.org/doc/html/rfc4511), [SAML](https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf), dostawcy zewnętrzni) dobrze sprawdza się [Dex](/katalog/dex); dla pełnego, headless serwera [OAuth2](https://oauth.net/2/)/OIDC — [Ory Hydra](/katalog/ory-hydra). Konfigurację trzymasz deklaratywnie:

```yaml
# Dex: jeden punkt OIDC przed wieloma źródłami (fragment)
issuer: https://auth.eiac.dev/dex
connectors:
  - type: ldap
    id: corp
    name: Active Directory
    config: { host: ldap.eiac.dev:636 }
staticClients:
  - id: argo-cd
    name: Argo CD
    redirectURIs: ["https://cd.eiac.dev/auth/callback"]
```

Efekt: jedno SSO dla całej platformy, niezależne od dostawcy infrastruktury.

## Sekrety: self-hosted źródło prawdy

Natywne KMS chmury to kolejny wektor lock-inu. Architektura suwerenna mandatuje **self-hostowany menedżer sekretów** jako jedyne źródło prawdy dla kluczy, haseł i certyfikatów — np. [Vault](/katalog/vault) / [OpenBao](/katalog/openbao), a dla zespołów ceniących prostotę [Infisical](/katalog/infisical). Aplikacje pobierają sekrety dynamicznie, więc nigdy nie lądują w repo ani w proprietarnym vaultcie dostawcy.

Druga, komplementarna droga to **szyfrowanie sekretów w Git** (GitOps-friendly): [SOPS](/katalog/sops) z kluczem [age](/katalog/age). Klucze pozostają jawne, wartości zaszyfrowane:

```yaml
# secrets.enc.yaml — wersjonowane w repo, wartości zaszyfrowane
db_password: ENC[AES256_GCM,data:9b1d…,tag:7f…]
api_token:   ENC[AES256_GCM,data:0c44…,tag:a1…]
```

W modelu GitOps sekrety wstrzykuje się do klastra dopiero przy synchronizacji — np. przez [Argo CD Vault Plugin](/katalog/argocd-vault-plugin), który zamienia placeholdery na wartości z backendu. Wybór „SOPS vs serwer sekretów" to kompromis: SOPS jest prosty i w pełni w repo; serwer daje dynamiczne, krótkożyciowe poświadczenia i centralną rotację.

## Policy-as-code: bramka, nie audyt

Trzeci filar to polityki egzekwowane automatycznie, opisane jako kod. W CI działają jako bramki ([OPA](/katalog/open-policy-agent)/Conftest, Checkov), a w klastrze jako admission control ([OPA Gatekeeper](/katalog/gatekeeper)). Przykład reguły wiążącej bezpieczeństwo z suwerennością:

```rego
package eiac.security

deny contains msg if {
  input.kind == "Deployment"
  some c in input.spec.template.spec.containers
  not c.securityContext.readOnlyRootFilesystem
  msg := sprintf("kontener %q musi mieć readOnlyRootFilesystem", [c.name])
}
```

Ta sama polityka chroni zmianę człowieka i agenta — bo działa na artefakcie, nie na autorze. To właśnie czyni ją skalowalną przy wolumenie zmian generowanych maszynowo.

## Nowy wymiar: tożsamość nie-ludzka dla agentów

Platforma agentowa dokłada wymóg, którego klasyczny IDP nie miał: **agent musi mieć własną, ograniczoną tożsamość** — nie działać z poświadczeniami człowieka, który go uruchomił. Bez tego autonomia jest nieaudytowalna („kto to zrobił?") i ma zbyt szeroki promień rażenia. Wzorce:

- **Tożsamość nie-ludzka** z wąskim zakresem (co agent może dotknąć), brokerowana przez [Dex](/katalog/dex)/[Ory Hydra](/katalog/ory-hydra).
- **Krótkożyciowe poświadczenia** z [Vault](/katalog/vault)/[OpenBao](/katalog/openbao), wydawane na czas zadania — nie statyczne sekrety.
- **Izolacja workspace** dla równoległych przebiegów agentów, by nie kolidowały i nie eskalowały uprawnień.
- **Ślad i provenance** — każda akcja agenta zalogowana, artefakty podpisane.

```hcl
# Vault: krótkożyciowe poświadczenia dla agenta zamiast statycznego sekretu
path "database/creds/agent-readonly" {
  capabilities = ["read"]   # TTL np. 15 min, automatyczna rotacja
}
```

To domyka wątek z [Deterministycznego szkieletu](/blog/deterministyczny-szkielet-adp): bez tożsamości nie-ludzkiej i krótkożyciowych poświadczeń nie da się bezpiecznie podnieść poziomu autonomii.

## Jak to się składa w całość

Trzy filary Security Plane działają razem: **tożsamość** mówi *kto/co* (ludzie i agenci), **sekrety** dają *bezpieczny dostęp* (dynamiczny, lokalny), **policy-as-code** egzekwuje *co wolno* (deklaratywnie, w bramce). Wszystkie trzy są self-hostowane i opisane jako kod — dzięki czemu spełniają jednocześnie wymóg suwerenności (lokalny root of trust) i wymóg audytowalnej autonomii (ślad, granice, prowienancja), o których pisaliśmy w kontekście [DORA](https://eur-lex.europa.eu/eli/reg/2022/2554/oj) i [AI Act](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai).

## Podsumowanie

Security Plane to nie zestaw dodatków, lecz płaszczyzna przecinająca platformę. Niezależny broker tożsamości, self-hostowane sekrety i policy-as-code lokalizują root of trust w organizacji, a tożsamość nie-ludzka rozszerza ten model na agentów. To fundament, na którym stoją zarówno suwerenność (kontrola nad każdą warstwą), jak i bezpieczna autonomia (audytowalne granice działania). Bez tej płaszczyzny reszta serii pozostaje teorią. Jak w homelab: dopóki nie ogarniesz lokalnego PKI, tożsamości i sekretów, każda „automatyzacja" powyżej stoi na piasku.

---


# Open source ≠ suwerenność: licencje i co-option chmury

URL: https://eiac.dev/blog/open-source-a-suwerennosc
Filar: Infrastructure-as-Code
Data: 2026-04-24
Tagi: sovereignty, open-source, licensing, iac
Skrót: Otwarta licencja nie wystarcza do suwerenności. Open-core, zmiany licencji (BSL/SSPL), repackaging przez chmury i przejęcia — oraz test, który naprawdę definiuje sovereign-ready tooling.

W [Suwerennym IDP](/blog/suwerenny-idp-exit-by-design) założyłem, że fundamentem przenośności jest otwarte tooling. Sam przez lata powtarzałem sobie wygodny mit: „open source jest z definicji suwerenny i wolny od lock-inu". Nauczyłem się — nieraz boleśnie — że to nieprawda, a trend idzie w niekorzystną stronę. Otwarta licencja to warunek konieczny, ale daleko niewystarczający.

<div class="callout">
<strong>Teza</strong>
<p>Testem suwerenności nie jest to, czy narzędzie ma licencję open source. Testem jest, czy organizacja może je <em>self-hostować, operować i zmigrować</em> bez zależności od jednego podmiotu komercyjnego.</p>
</div>

## Cztery sposoby, w jakie „otwarte" przestaje być wolne

Open source bywa fundamentem suwerenności, ale kilka strukturalnych nacisków tę przewagę eroduje.

| Trend | Przykłady | Ryzyko dla suwerenności |
|---|---|---|
| **Open core** | Backstage, Elasticsearch, MongoDB, Terraform | Rdzeń otwarty, funkcje enterprise zamknięte — migrujesz do open source, a potem wpadasz w komercyjny lock-in na kluczowych zdolnościach |
| **Zmiany licencji** | Elastic (SSPL), MongoDB (AGPL→SSPL), HashiCorp (BSL) | Przejście z licencji permisywnej łamie zaufanie i retroaktywnie ogranicza użycie |
| **Co-option przez chmury** | repackaging projektów jako usługi zarządzane | Hyperscaler dokłada warstwy proprietary, odtwarzając lock-in, którego projekt miał unikać |
| **Przejęcia** | Red Hat (IBM), GitHub (Microsoft), HashiCorp (IBM) | Priorytety społeczności zmieniają się po akwizycji |

Każdy z tych mechanizmów może zamienić „otwarte" narzędzie w pułapkę — nie z dnia na dzień, lecz stopniowo, gdy już jesteś od niego zależny.

## Praktyczne wnioski

Z tej diagnozy płyną trzy zasady projektowania suwerennego toolingu:

- **Suwerenność wymaga czystego, społecznościowego open source.** Modele open-core to świetne punkty wejścia, ale ich warstwy enterprise SaaS są produktami komercyjnymi. Prawdziwa autonomia opiera się na nieskrępowanym, swobodnie modyfikowalnym rdzeniu.
- **Zmiany licencji erodują zaufanie.** Audytuj licencje przed adopcją i monitoruj zmiany. To argument za stawianiem na projekty pod skrzydłami fundacji (Linux Foundation, CNCF), które gwarantują, że rdzeń pozostanie otwarty i zarządzany przez społeczność.
- **Chmury co-optują open source.** Usługi zarządzane oparte na otwartych projektach często dokładają warstwy proprietary, odtwarzające lock-in, którego oryginał miał unikać.

## Case: OpenTofu jako odpowiedź na BSL

Najczystszy przykład to fork [Terraform](/katalog/terraform) po zmianie jego licencji na BSL. Społeczność odpowiedziała [OpenTofu](/katalog/opentofu) — zgodnym składniowo (HCL, format stanu, ekosystem providerów) zamiennikiem pod **Linux Foundation**, co gwarantuje, że silnik definiujący infrastrukturę organizacji pozostaje otwarty i wolny od przechwycenia przez jeden podmiot.

W praktyce dla większości projektów migracja jest niemal wymianą binarki:

```bash
# ten sam kod .tf, moduły i providerzy — inna komenda
tofu init
tofu plan
tofu apply
```

To pokazuje, czym jest „sovereign-ready": nie samą licencją, lecz realną możliwością odejścia bez przepisywania całej infrastruktury.

## Kryteria wyboru sovereign-ready tooling

Praktyczna lista kontrolna przy ocenie narzędzia do platformy:

- **Self-hosting** — czy da się uruchomić w pełni we własnej jurysdykcji, także air-gapped?
- **Migrowalność** — czy istnieje droga wyjścia bez zależności od jednego dostawcy (otwarte formaty, standardy)?
- **Governance** — czy projekt jest pod fundacją / wieloma kontrybutorami, czy kontroluje go jeden komercyjny właściciel?
- **Licencja** — permisywna/community, nie BSL/SSPL; z historią stabilności.
- **Brak ukrytego open-core** — czy funkcje krytyczne dla Ciebie są w otwartym rdzeniu, czy za płatną bramką?

Przez ten pryzmat warto patrzeć na cały katalog narzędzi platformy — od VCS ([Gitea](/katalog/gitea)), przez GitOps ([Argo CD](/katalog/argo-cd)), po rejestry ([Harbor](/katalog/harbor)).

## Niuans: governance to też proces, nie tylko licencja

Suwerenność toolingu łączy się z szerszym tematem zarządzania zmianą — jak projekt (i Twoja organizacja) panuje nad wersjami, kompatybilnością i procesem wydań. To, co pisaliśmy o deterministycznym, opartym na regułach procesie w [artykule o wersjonowaniu](/blog/wersjonowanie-semver-conventional-commits), dotyczy także zaufania do zależności: przewidywalny, otwarty proces wydawniczy jest częścią „sovereign-ready".

## Podsumowanie

„Open source" na etykiecie nie wystarcza. Liczy się, czy możesz narzędzie self-hostować, nim operować i od niego odejść — bez łaski jednego komercyjnego właściciela. Open-core, zmiany licencji, co-option przez chmury i przejęcia to realne wektory utraty autonomii. Dlatego sovereign-ready tooling rozpoznajesz nie po licencji, lecz po przenośności i governance — a fundacje takie jak Linux Foundation czy CNCF są tu Twoim najlepszym sojusznikiem. Następnym razem, gdy zobaczysz łatkę „open source", zadaj trzy pytania: self-host, operowanie, wyjście. Reszta to marketing.

---


# Suwerenne AI w platformie: open-weight, lokalne GPU i ochrona IP

URL: https://eiac.dev/blog/suwerenne-ai-open-weight
Filar: Security-as-Code
Data: 2026-04-17
Tagi: sovereignty, ai, llm, ip, security
Skrót: Bez modelu open-weight na własnej infrastrukturze data residency jest iluzją — najcenniejsze aktywa wyciekają przez asystenta. Suwerenne AI jako zarządzanie ryzykiem IP i ciągłości, z trzeźwym uznaniem kosztów.

W [Suwerennym IDP](/blog/suwerenny-idp-exit-by-design) ustaliłem, że suwerenność to przenośność workflowów, a każdy komponent platformy podlega tej samej ocenie co infrastruktura. Jest jednak jeden, który łamie tę ocenę w nowy sposób — **asystent AI**. I to on spędza mi sen z powiek najbardziej. Tradycyjny Copilot nieustannie wysyła fragmenty kodu i kontekst na serwery dostawcy, do przetwarzania i potencjalnego treningu. To nie jest „przetwarzanie danych" w starym sensie — to ciągły, trudny do zauważenia wyciek własności intelektualnej poza granicę suwerenności.

<div class="callout">
<strong>Teza</strong>
<p>Jeśli Twój asystent AI przetwarza kod na cudzych serwerach, „data residency" reszty platformy nic nie znaczy. Algorytmy, logika biznesowa i definicje infrastruktury wyciekają tą samą drogą, którą miały chronić wszystkie inne kontrole.</p>
</div>

## Dlaczego to nowy rodzaj ryzyka

Klasyczne kontrole suwerenności pilnują, gdzie *spoczywają* dane. Asystent AI obchodzi je, bo dane *w ruchu* — prompt, otaczający kod, definicje infry, komunikaty błędów — opuszczają organizację przy każdym zapytaniu. Co gorsza, mogą zostać wchłonięte przez obce, scentralizowane pipeline'y treningowe, nad którymi nie masz żadnej kontroli ani widoczności.

Do tego dochodzi ryzyko ciągłości. Zdolność hostowana w jednej jurysdykcji może zostać odcięta z dnia na dzień decyzją administracyjną — bez uprzedzenia i bez prawa odwołania. Dla zespołu, który wpiął obcy model w krytyczną ścieżkę wytwarzania, to nie teoretyczne ryzyko, lecz nagłe zatrzymanie pracy.

## Optyka: suwerenność to optionality

Suwerenne AI nie znaczy „zakaz używania zewnętrznych modeli". Znaczy **optionality** — zdolność do uruchomienia całego cyklu wytwarzania na własnych warunkach, gdy zajdzie potrzeba. W praktyce sprowadza się to do trzech decyzji architektonicznych:

- **Modele open-weight** — o otwartych wagach, które możesz pobrać, uruchomić i audytować, zamiast czarnej skrzynki za API.
- **Hosting lokalny lub suwerenny** — na własnym GPU albo u dostawcy w Twojej jurysdykcji, tak by zapytania nie opuszczały granicy.
- **Routing zapytań AI przez platformę** — wszystkie zapytania asystentów idą przez kontrolowany punkt, nie bezpośrednio do obcego SaaS.

Dzięki temu kod, telemetria i definicje infry pozostają pod kontrolą organizacji i nie są ingerowane przez zewnętrzne modele.

## Jak to wygląda na platformie

Wzorzec to brama (gateway) wystawiająca zgodne z OpenAI API, za którą stoi lokalnie hostowany model — np. uruchomiony na [Kubernetes](/katalog/kubernetes) (lub lekkim [k3s](/katalog/k3s) na brzegu z GPU). Asystenci w IDE i agenci w pipeline kierują ruch do tej bramy, nie na zewnątrz.

```yaml
# wdrożenie lokalnej bramy modelu z dostępem do GPU (szkic)
apiVersion: apps/v1
kind: Deployment
metadata: { name: llm-gateway, namespace: ai }
spec:
  replicas: 2
  template:
    spec:
      containers:
        - name: gateway
          image: registry.eiac.dev/ai/openai-compatible-gateway:1.0.0
          resources:
            limits: { nvidia.com/gpu: "1" }
          env:
            - name: MODEL
              value: "open-weight-coder"
```

Sekrety dostępowe do bramy i providerów trzymasz w [Vault](/katalog/vault)/[OpenBao](/katalog/openbao) (nie w repo), a do oceny jakości i bezpieczeństwa modeli oraz promptów używasz deklaratywnych ewaluacji i red-teamingu — np. [promptfoo](/katalog/promptfoo) jako krok w CI. Provenance artefaktów generowanych z udziałem AI warto podpisywać (np. [gitsign](/katalog/gitsign)), by dało się udowodnić ich pochodzenie.

```yaml
# ewaluacja i red-teaming modelu jako bramka jakości (promptfoo)
prompts: ["{{zadanie}}"]
providers: ["http://llm-gateway.ai.svc/v1"]
redteam:
  plugins: [prompt-injection, pii-leak]
```

## Kompromisy: czego to kosztuje

Suwerenne AI nie jest darmowe. Open-weight modele bywają o krok za najlepszymi zamkniętymi frontier-models, lokalny hosting wymaga GPU i utrzymania, a brama to dodatkowy komponent do obsłużenia. To realny koszt — który zestawiasz z ryzykiem wycieku IP i utraty ciągłości. Dla wielu zespołów rozsądny jest model mieszany: wrażliwe ścieżki przez model lokalny, mniej wrażliwe — przez zewnętrzny, ale zawsze za kontrolowaną bramą, którą da się przełączyć.

## Styk z regulacją

Suwerenne AI spotyka się z **[AI Act](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai)** w dwóch punktach: transparentności (lineage modelu — co i na czym działa) oraz nadzoru i śladu (logowanie zapytań/wyników w granicy organizacji). Lokalna brama daje naturalny punkt, w którym ten ślad powstaje i pozostaje pod kontrolą. Mapowanie wymogów AI Act na cykl wytwarzania rozwijamy w [AI Act a agentowy SDLC](/blog/ai-act-a-agentowy-sdlc).

## Podsumowanie

AI jest dziś częścią platformy — więc podlega tej samej ocenie suwerenności co reszta. Bez opcji modelu open-weight na własnej infrastrukturze data residency jest iluzją: najcenniejsze aktywa wyciekają przez asystenta. Suwerenne AI to nie ideologia, lecz zarządzanie ryzykiem IP i ciągłości — z trzeźwym uznaniem jego kosztów. To zarazem warstwa, w której rodzi się ślad wymagany przez AI Act, do którego przechodzę dalej. I tak, wiem — lokalny model kosztuje: sprzęt, ludzi, utrzymanie. Ale policz kiedyś, ile warta jest Twoja własność intelektualna, zanim uznasz, że to za drogo.

---


# AI Act a agentowy SDLC: regulacja kontra autonomia

URL: https://eiac.dev/blog/ai-act-a-agentowy-sdlc
Filar: Security-as-Code
Data: 2026-04-10
Tagi: ai-act, agents, compliance, governance, eu
Skrót: Wymogi AI Act — nadzór człowieka, ślad, transparentność, zarządzanie ryzykiem — mapują się niemal jeden do jednego na deterministyczny szkielet platformy agentowej. Regulacja jako specyfikacja, nie hamulec.

W [czterech poziomach](/blog/cztery-poziomy-agentowego-wytwarzania) pokazałem, że im wyżej w autonomii, tym ważniejszy staje się nadzór i ślad. To nie jest tylko dobra inżynieria — to dokładnie to, czego żąda **[AI Act](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai)**. Wiem, „regulacja" brzmi jak hamulec. Ale pokażę Ci, że jej wymogi mapują się niemal jeden do jednego na deterministyczny szkielet platformy agentowej (ADP) — czyli na to, co i tak musisz zbudować.

<div class="callout">
<strong>Teza</strong>
<p>AI Act nie jest przeszkodą dla agentów — jest specyfikacją tego, co i tak musi mieć dobra platforma agentowa: nadzór człowieka, logowanie, transparentność i zarządzanie ryzykiem. Im wyższy poziom autonomii, tym mocniejsze wymagane guardrails.</p>
</div>

<div class="callout">
<strong>Uwaga</strong>
<p>To analiza techniczna, nie porada prawna. Zakres obowiązków AI Act zależy od roli (dostawca, podmiot stosujący), klasy ryzyka i przeznaczenia systemu.</p>
</div>

## AI Act w pigułce: regulacja oparta na ryzyku

AI Act klasyfikuje systemy AI według ryzyka, a obowiązki rosną wraz z nim:

- **Niedopuszczalne** — praktyki zakazane (obowiązują od lutego 2025).
- **Wysokie ryzyko** — np. rekrutacja, scoring kredytowy, egzekwowanie prawa; pełen zestaw obowiązków (zarządzanie ryzykiem, nadzór człowieka, logi, dokumentacja, jakość danych).
- **Ograniczone** — obowiązki transparentności (użytkownik wie, że ma do czynienia z AI / treścią generowaną).
- **Minimalne** — większość zastosowań; bez dodatkowych wymogów.

Kalendarz (stan na 2026): obowiązki dla **GPAI** (modeli ogólnego przeznaczenia) są stosowane od 2 sierpnia 2025, a pełne uprawnienia egzekucyjne AI Office aktywują się 2 sierpnia 2026. Terminy dla systemów wysokiego ryzyka zostały przesunięte (w ramach „Digital Omnibus", porozumienie z 7 maja 2026, w trakcie formalnego przyjęcia): Annex III (samodzielne) do **2 grudnia 2027**, Annex I (wbudowane w produkty) do **2 sierpnia 2028**. GPAI obecne na rynku przed 2 sierpnia 2025 mają czas na zgodność do 2 sierpnia 2027.

## Dwa różne pytania

Mówiąc o „AI i regulacji", łatwo pomieszać dwie sprawy:

1. **Używasz AI do wytwarzania** (agenci w pipeline). Tu zwykle nie budujesz systemu wysokiego ryzyka — kluczowe są ład, nadzór i audytowalność *procesu*.
2. **Dostarczasz funkcje oparte na AI** w produkcie. Tu może wejść reżim wysokiego ryzyka lub obowiązki transparentności wobec użytkowników.

Ten artykuł skupia się na (1) — agentowym SDLC — bo to tam AI Act spotyka się z architekturą platformy. Ale ta sama platforma pomaga też spełnić (2).

## Mapowanie wymogów na ścieżki value streamu

Najciekawsze jest to, jak czysto wymogi AI Act odwzorowują się na elementy ADP opisane wcześniej:

| Wymóg AI Act | Element platformy agentowej |
|---|---|
| Nadzór człowieka (human oversight) | poziomy in/on/orchestrator — człowiek w/na pętli, auto-promocja tylko dla low-risk |
| Logowanie i rejestry (record-keeping) | obserwowalność + ślad audytowy, tożsamość nie-ludzka (kto/co zrobił) |
| Transparentność | provenance artefaktów — podpisy ([gitsign](/katalog/gitsign)), jawne pochodzenie zmian |
| Zarządzanie ryzykiem | klasyfikacja ryzyka + policy-as-code jako bramka ([OPA](/katalog/open-policy-agent), [Gatekeeper](/katalog/gatekeeper)) |
| Jakość/ład danych | sekrety i dostęp (Security Plane), warstwy semantyczne nad danymi |
| Testy i monitorowanie | walidacja-pętla + ewaluacja/red-teaming ([promptfoo](/katalog/promptfoo)), runtime ([Falco](/katalog/falco)) |

Innymi słowy: deterministyczny szkielet, który i tak jest potrzebny, by agenci działali bezpiecznie, jest jednocześnie warstwą zgodności z AI Act.

## Nadzór jako funkcja poziomu autonomii

Kluczowa intuicja: **im mniej człowieka w pętli, tym mocniejsze muszą być automatyczne dowody i granice.** AI Act wymaga „odpowiedniego nadzoru człowieka" — a poziomy z [czterech poziomów](/blog/cztery-poziomy-agentowego-wytwarzania) dają temu konkretny kształt:

- na poziomie 1-2 nadzór jest wprost (człowiek akceptuje / weryfikuje zachowanie),
- na poziomie 3 przenosi się na **reguły promocji** — człowiek projektuje politykę, a nie ogląda każdą zmianę,
- przy autonomii (poziom 4) nadzór to **granice i progi ryzyka** plus pełny ślad, który pozwala odtworzyć każdą decyzję.

Klasyfikacja ryzyka zmiany staje się więc nie tylko mechanizmem przepustowości, ale i mechanizmem zgodności:

```rego
# tylko zmiany low-risk mogą iść bez człowieka; reszta wymaga nadzoru
package eiac.aiact

auto_promote if {
  input.change.risk == "low"
  input.validation.status == "green"
  input.actor.type == "agent"
  input.provenance.signed == true   # podpisany artefakt (transparentność)
}
```

Reguła łączy trzy wymogi naraz: zarządzanie ryzykiem (klasa), nadzór (co wolno bez człowieka) i transparentność (podpis). Wszystko jako kod, więc audytowalne.

## GPAI, open-weight i transparentność

Jeśli używasz modeli, AI Act dokłada wątek transparentności i dokumentacji (zwłaszcza dla GPAI). Tu zazębia się to z [Suwerennym AI](/blog/suwerenne-ai-open-weight): lokalna brama modelu daje naturalny punkt, w którym powstaje ślad zapytań i odpowiedzi, a wybór modelu open-weight ułatwia wykazanie lineage (co, na czym, z jakimi danymi). Suwerenność i zgodność z AI Act często prowadzą do tej samej decyzji architektonicznej.

## Praktyka: zgodność jako właściwość platformy

Tak jak przy [DORA](/blog/dora-w-praktyce-platformy), najmocniejszy wniosek jest ten sam: nie buduj „zgodności z AI Act" jako osobnego procesu obok platformy. Wbuduj ją w platformę — jako polityki, ślad, prowienancję i progi ryzyka, które i tak są potrzebne do bezpiecznej autonomii. Wtedy zgodność jest produktem ubocznym dobrze zaprojektowanego ADP, a nie dodatkowym obciążeniem.

## Podsumowanie

AI Act i agentowy SDLC nie są w konflikcie — opisują tę samą rzecz z dwóch stron. Regulacja mówi „musi być nadzór, ślad, transparentność i zarządzanie ryzykiem"; dobra platforma agentowa mówi „bez tego autonomia jest niebezpieczna". Deterministyczny szkielet ADP jest więc jednocześnie systemem bezpieczeństwa i warstwą zgodności. Im wcześniej go zbudujesz, tym mniej będzie bolał każdy kolejny termin z kalendarza AI Act. Potraktuj tę regulację nie jak biurokrację do odhaczenia, lecz jak listę kontrolną dobrej platformy agentowej — i tak ją odhaczysz przy okazji.

---


# DORA w praktyce platformy: testowalne strategie wyjścia

URL: https://eiac.dev/blog/dora-w-praktyce-platformy
Filar: Security-as-Code
Data: 2026-04-03
Tagi: dora, sovereignty, compliance, gitops, eu
Skrót: DORA zamienia strategię wyjścia z dokumentu w udowadnialną zdolność operacyjną. Jak warstwy platformy — IaC, GitOps, policy-as-code — przekładają się wprost na zgodność.

W [Suwerennym IDP](/blog/suwerenny-idp-exit-by-design) pokazałem, że „exit-by-design" czyni strategię wyjścia funkcją techniczną. Dla sektora finansowego w UE to już nie jest dobra praktyka — to wymóg prawny. **[DORA](https://eur-lex.europa.eu/eli/reg/2022/2554/oj)** (Digital Operational Resilience Act) zamienia odporność operacyjną z deklaracji w coś, co trzeba *udowodnić i przetestować*. Zobaczmy, jak warstwy platformy — IaC, GitOps, policy-as-code — przekładają się wprost na zgodność.

<div class="callout">
<strong>Teza</strong>
<p>DORA nie pyta „czy macie dokument strategii wyjścia?". Pyta „czy potraficie ją <em>wykonać</em> bez przerwania działania?". To czyni z odporności właściwość architektury, nie segregatora.</p>
</div>

<div class="callout">
<strong>Uwaga</strong>
<p>To analiza techniczna, nie porada prawna. Zakres i interpretacja DORA zależą od podmiotu i nadzorcy — tu patrzymy wyłącznie na konsekwencje dla architektury platformy.</p>
</div>

## Co DORA wymaga (w skrócie technicznym)

DORA obowiązuje podmioty finansowe i ich dostawców ICT. Z perspektywy platformy liczą się przede wszystkim:

- **Mapowanie zależności ICT** — musisz wiedzieć (i umieć wykazać), od jakich dostawców i komponentów zależysz.
- **Ryzyko koncentracji (CTPP)** — zakaz nadmiernej zależności od jednego krytycznego dostawcy ICT (critical third-party provider).
- **Testowalne strategie wyjścia** — utrzymywane i *przetestowane* ścieżki migracji bez zakłócenia działania.
- **Odporność operacyjna i testowanie** — zdolność do przetrwania i odtworzenia po incydencie.

Kluczowe: nie wystarczy strategię *opisać*. Trzeba mieć **operacyjną zdolność** jej wykonania. A tę da się zbudować tylko przez fundamentalne odsprzężenie wytwarzania i dostarczania od konkretnego dostawcy infrastruktury.

## Mapowanie wymogów na warstwy platformy

| Wymóg DORA | Mechanizm platformy |
|---|---|
| Mapowanie zależności ICT | wszystko-jako-kod w repo → zależności są jawne i audytowalne |
| Unikanie koncentracji CTPP | multi-cloud przez abstrakcję IaC + framework-agnostyczna orkiestracja |
| Testowalna strategia wyjścia | GitOps jako odtwarzalny stan → DR = wskazanie kontrolerowi nowego klastra |
| Dowody zgodności | policy-as-code jako bramki + ślad audytowy z Gita |
| Odporność/odtwarzanie | środowiska deklaratywne, reprodukowalne z repo |

## Abstrakcja IaC: warunek unikania koncentracji

Ryzyka koncentracji nie da się ograniczyć, jeśli wdrożenie jest „zapieczone" w API jednego dostawcy. Dlatego infrastrukturę definiujesz w sposób cloud-agnostyczny — przez [OpenTofu](/katalog/opentofu) (lub [Terraform](/katalog/terraform)) z modułami, które da się skierować na różnych dostawców:

```hcl
# moduł sieci wołany dla różnych dostawców z tego samego kodu
module "vpc" {
  source   = "git::https://git.eiac.dev/eiac/modules.git//network?ref=v1.4.0"
  provider = var.target          # sovereign-eu | global-aws
  cidr     = "10.0.0.0/16"
}
```

Ten sam moduł, dwa cele wdrożenia — to techniczny fundament tezy „nie jesteśmy nadmiernie zależni od jednego dostawcy". Multi-cloud przestaje być hasłem, a staje się weryfikowalną własnością kodu.

## GitOps: strategia wyjścia, którą da się wykonać

Skoro cały stan systemu żyje jako kod, „wyjście" przestaje być projektem migracyjnym, a staje się operacją. Kontroler GitOps ([Argo CD](/katalog/argo-cd) / [Flux](/katalog/flux)) odtwarza środowisko z repozytorium na dowolnym zgodnym klastrze:

<figure>
<svg viewBox="0 0 720 132" role="img" aria-label="Exit jako operacja: wyzwalacz, provisioning klastra przez tofu apply, reconcile Argo CD z repo, odtworzone środowisko">
  <g fill="none" stroke="currentColor" stroke-width="1.5">
    <rect x="16" y="42" width="150" height="48" rx="6"/>
    <rect x="200" y="42" width="160" height="48" rx="6"/>
    <rect x="394" y="42" width="166" height="48" rx="6"/>
    <rect x="588" y="42" width="116" height="48" rx="6" stroke="var(--color-rust)"/>
  </g>
  <g stroke="currentColor" stroke-width="1.5">
    <line x1="166" y1="66" x2="194" y2="66"/>
    <line x1="360" y1="66" x2="388" y2="66"/>
    <line x1="560" y1="66" x2="582" y2="66"/>
  </g>
  <g fill="currentColor">
    <path d="M194 62 L200 66 L194 70 Z"/>
    <path d="M388 62 L394 66 L388 70 Z"/>
    <path d="M582 62 L588 66 L582 70 Z"/>
  </g>
  <g font-family="'Space Grotesk', system-ui, sans-serif" font-size="12.5" fill="currentColor" text-anchor="middle">
    <text x="91" y="62">katastrofa /</text>
    <text x="91" y="78">nakaz wyjścia</text>
    <text x="280" y="62">provisioning klastra</text>
    <text x="280" y="78">u innego dostawcy</text>
    <text x="477" y="62">Argo CD →</text>
    <text x="477" y="78">reconcile z repo</text>
    <text x="646" y="62" fill="var(--color-rust)">środowisko</text>
    <text x="646" y="78" fill="var(--color-rust)">odtworzone</text>
  </g>
  <g font-family="'Space Mono', monospace" font-size="10" fill="var(--color-muted)" text-anchor="middle">
    <text x="280" y="106">tofu apply</text>
  </g>
</svg>
<figcaption>Exit = DR jako operacja: provisioning u innego, suwerennego dostawcy, skierowanie kontrolera GitOps na nowy klaster i odtworzenie środowiska z repo.</figcaption>
</figure>

To jest sedno „testowalnej strategii wyjścia": skoro DR i exit to ta sama operacja (re-point kontrolera + reconcile), możesz ją **przećwiczyć** — a przećwiczona migracja to dokładnie to, czego DORA wymaga. Na [Kubernetes](/katalog/kubernetes) (lub lekkim [k3s](/katalog/k3s) na zapasowej lokacji) odtworzenie jest powtarzalne i mierzalne.

## Dowody zgodności jako kod

DORA wymaga wykazywania zgodności. Zamiast ręcznych audytów, czynisz reguły maszynowo egzekwowalne i samodokumentujące — policy-as-code w pipeline (np. [OPA](/katalog/open-policy-agent)). Każde uruchomienie zostawia ślad: co sprawdzono, z jakim wynikiem.

```rego
# przykładowa reguła zgodna z wymogiem rezydencji danych
package eiac.dora

deny contains msg if {
  input.resource.type == "database"
  not startswith(input.resource.region, "eu-")
  msg := "dane regulowane muszą pozostać w regionie UE"
}
```

Reguła egzekwowana w CI (i ślad z Gita) jest jednocześnie kontrolą i dowodem — bez osobnego procesu audytowego.

## Granica: czego platforma nie załatwi

Uczciwie: platforma spełnia *techniczną* część DORA. Reszta — rejestr informacji o dostawcach, raportowanie incydentów do nadzorcy, testy odporności (w tym TLPT dla większych podmiotów), zarządzanie ryzykiem na poziomie organizacji — to procesy i obowiązki wykraczające poza kod. Architektura jest warunkiem koniecznym zgodności, nie wystarczającym.

## Podsumowanie

DORA przesuwa ciężar z „opisz strategię wyjścia" na „udowodnij, że ją wykonasz". Everything-as-code daje mapę zależności, abstrakcja IaC ogranicza koncentrację, GitOps czyni z exitu rutynową operację, a policy-as-code dostarcza dowodów. To nie przypadek, że to ta sama architektura, którą opisałem jako suwerenną — odporność i suwerenność wyrastają z tego samego korzenia. Uczciwie: sam kod nie załatwi zgodności w całości; rejestr dostawców, raportowanie incydentów i procesy to wciąż robota ludzi. Ale bez tej architektury reszta nie ma się na czym oprzeć. W kolejnej części patrzę na drugą wielką regulację: [AI Act a agentowy SDLC](/blog/ai-act-a-agentowy-sdlc).

---


# Suwerenny IDP: exit-by-design jako architektura

URL: https://eiac.dev/blog/suwerenny-idp-exit-by-design
Filar: Infrastructure-as-Code
Data: 2026-03-30
Tagi: platform-engineering, sovereignty, gitops, iac, eu
Skrót: Suwerenność to nie miejsce przechowywania danych, lecz przenośność workflowów. Jak everything-as-code i GitOps zamieniają strategię wyjścia z dokumentu w funkcję techniczną.

W [wprowadzeniu](/blog/platform-engineering-normalizacja-pracy) platforma była sposobem na uspójnienie pracy. Tu dochodzi drugi wymiar, równie strukturalny: **suwerenność** — zdolność organizacji do działania niezależnie od nacisków prawnych, handlowych czy geopolitycznych. Teza, którą rozwijam, jest prosta i niewygodna: o suwerenności nie decyduje to, *gdzie* leżą dane, lecz *czy potrafisz przenieść swoje workflowy* gdzie indziej, gdy przyjdzie potrzeba. Brzmi abstrakcyjnie? Do czasu, aż dostawca zmieni cennik albo licencję i nagle „gdzie leżą dane" przestaje być Twoim największym problemem.

<div class="callout">
<strong>Teza</strong>
<p>Data residency to nie to samo co suwerenność. Suwerenność jest własnością przenośności procesu, a jej technicznym nośnikiem jest „everything-as-code" — przesunięcie źródła zaufania z vendora do Twoich repozytoriów Git.</p>
</div>

## Legal sandwich: dlaczego residency nie wystarcza

Współczesne przedsiębiorstwo działa w „prawnej kanapce": sprzeczne jurysdykcje potrafią się wykluczać. Klasyczny przykład to napięcie między amerykańskim [CLOUD Act](https://en.wikipedia.org/wiki/CLOUD_Act) (który może zmusić firmę z USA do wydania danych niezależnie od tego, gdzie fizycznie leżą) a unijnym [RODO](https://eur-lex.europa.eu/eli/reg/2016/679/oj) (które takiego transferu zakazuje). Dostawca z USA przechowujący dane w Paryżu czy Frankfurcie i tak jest „w środku" — a wraz z nim jego klient.

Z tego płynie wniosek, który zmienia projektowanie platform: jeśli VCS, orkiestrator wdrożeń, dostawca tożsamości i asystent AI podlegają obcej jurysdykcji, to infrastruktura spełniająca data residency daje **tylko częściową suwerenność**. Każdy komponent platformy trzeba poddać tej samej ocenie, co warstwę infrastruktury.

## Pięć planes: architektura zamiast warstw

Suwerenny IDP projektuje się jako **planes** (płaszczyzny) — wymienne, komponowalne zdolności łączone przez standardowe API — a nie sztywne warstwy o monolitycznej zależności. Ta komponowalność jest fundamentem strategii wyjścia.

- **Developer Control Plane** — portal, IDE/CDE i suwerenne AI; punkt wejścia ukrywający złożoność.
- **Integration & Delivery Plane** — silnik mechaniczny: VCS ([Gitea](/katalog/gitea)/Forgejo), CI runners, orkiestrator i GitOps ([Argo CD](/katalog/argo-cd)/[Flux](/katalog/flux)).
- **Resource Plane** — compute/sieć/storage u dostawców suwerennych i globalnych (świadomie pofragmentowane, by ograniczyć ryzyko jednego dostawcy).
- **Security Plane** — lokalna tożsamość, sekrety i polityki (rozwijamy w [Security Plane](/blog/security-plane-sekrety-tozsamosc-policy)).
- **Observability Plane** — metryki, logi, tracing oraz FinOps/GreenOps.

Każda płaszczyzna jest wymienna — to czyni „exit" wykonalnym, a nie życzeniowym.

## Everything-as-code + GitOps = exit-by-design

Sercem podejścia jest bezkompromisowe egzekwowanie „everything-as-code". Definiując całą infrastrukturę — od load balancerów u dostawcy suwerennego po bucket S3 u globalnego — w deklaratywnym kodzie, traktujesz ją jako jednorazową i odtwarzalną. Wybór narzędzia ma tu znaczenie: ze względu na ryzyko zmian licencyjnych warto trzymać się silnika otwartego i fundacyjnego, jak [OpenTofu](/katalog/opentofu) (drop-in zamiennik [Terraform](/katalog/terraform) pod Linux Foundation) — wątek licencji rozwijamy w [Open source ≠ suwerenność](/blog/open-source-a-suwerennosc).

GitOps jest operacyjną ramą, która to spina: self-hostowany VCS jest jedynym źródłem prawdy dla kodu aplikacji **i** konfiguracji infrastruktury, a kontroler (np. Argo CD) nieustannie uzgadnia stan rzeczywisty z zadeklarowanym.

```yaml
# Argo CD: aplikacja, której źródłem prawdy jest repo na Gitei
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata: { name: web, namespace: argocd }
spec:
  project: default
  source:
    repoURL: https://git.eiac.dev/eiac/deploy.git
    path: clusters/sovereign-eu/web
    targetRevision: main
  destination:
    server: https://kubernetes.default.svc
    namespace: web
  syncPolicy:
    automated: { prune: true, selfHeal: true }
```

Konsekwencja jest mocna: skoro cały stan biznesu jest opisany jako kod w repo, to **disaster recovery (i exit) sprowadza się do wskazania kontrolerowi nowego klastra** u innego, suwerennego dostawcy i pozwolenia mu odtworzyć środowisko od zera. Strategia wyjścia przestaje być dokumentem w segregatorze, a staje się rutynowo wykonywaną operacją.

## Air-gapped: ostateczny test suwerenności

Dla obronności i części finansów połączenie z jakimkolwiek publicznym internetem (nawet suwerennym) bywa wykluczone. Zdolność do działania w pełni odizolowanym środowisku air-gapped to najtwardszy sprawdzian: jeśli platforma opiera się na self-hostowanych control planes, własnym rejestrze obrazów i otwartej orkiestracji, całość da się postawić w odciętym data center. To samo, co daje suwerenność, daje też odporność na odcięcie.

## Macierz walidacji: jak sprawdzić, czy jesteś suwerenny

Praktyczny test sprowadza się do trzech domen i kilku pytań, na które trzeba odpowiedzieć „tak":

| Domena | Pytanie kontrolne |
|---|---|
| Infrastruktura i dane | Czy IaC jest otwarte i wolne od restrykcyjnych licencji (OpenTofu vs proprietary)? Czy dane leżą wyłącznie w wybranej jurysdykcji, a dostawca jest odporny na eksterytorialne żądania? |
| Tooling i control plane | Czy VCS jest self-hostowany? Czy orkiestrator jest framework-agnostyczny (wdraża i do suwerennych, i globalnych bez vendor-specyficznych wtyczek)? Czy sekrety/IAM są self-hostowane, nie w natywnym KMS chmury? |
| AI i własność intelektualna | Czy asystenci AI/LLM są hostowani lokalnie/suwerennie? Czy masz gwarancję, że kod i telemetria nie zasilają obcych modeli? (rozwijamy w [Suwerenne AI](/blog/suwerenne-ai-open-weight)) |

## Kontekst UE: nie tylko RODO

Ruch w stronę suwerenności napędzają konkretne ramy: **[NIS2](https://digital-strategy.ec.europa.eu/en/policies/nis2-directive)** (cyberbezpieczeństwo w 18 sektorach krytycznych), **[EU Data Act](https://digital-strategy.ec.europa.eu/en/policies/data-act)**, inicjatywy jak [SecNumCloud](https://cyber.gouv.fr/enjeux-technologiques/cloud/) (Francja), [Gaia-X](https://gaia-x.eu/) czy [EU Cloud Rulebook](https://digital-strategy.ec.europa.eu/en/policies/cloud-computing). Najtwardsze wymogi techniczne stawia jednak **[DORA](https://eur-lex.europa.eu/eli/reg/2022/2554/oj)** wobec sektora finansowego — mapowanie zależności ICT, unikanie nadmiernej koncentracji u jednego dostawcy i utrzymywanie *przetestowanych* strategii wyjścia. Temu poświęcamy osobną część: [DORA w praktyce platformy](/blog/dora-w-praktyce-platformy).

## Podsumowanie

Suwerenny IDP to nie „chmura w UE", lecz architektura, w której każda płaszczyzna jest wymienna, a cały stan żyje jako kod w repozytorium pod Twoją kontrolą. Wtedy „exit" przestaje być ryzykiem do opisania w dokumencie, a staje się właściwością systemu — wykonywaną tak samo, jak każde inne wdrożenie. To również fundament, na którym da się spełnić wymogi DORA i bezpiecznie osadzić AI — co rozwijam w kolejnych częściach serii. Zrób sobie ten jeden test: gdyby jutro trzeba było przenieść wszystko do innego dostawcy, ile z tego pojedzie jednym `apply`? Odpowiedź mówi o Twojej suwerenności więcej niż jakikolwiek certyfikat.

---


# Deterministyczny szkielet platformy agentowej

URL: https://eiac.dev/blog/deterministyczny-szkielet-adp
Filar: SDLC / Policy-as-Code
Data: 2026-03-23
Tagi: platform-engineering, policy-as-code, ci, security, agents
Skrót: Nieprzewidywalną moc modeli zamienia w audytowalny wynik deterministyczny szkielet: walidacja-pętla, policy-as-code jako bramka, środowiska efemeryczne i tożsamość nie-ludzka.

W [poprzedniej części](/blog/cztery-poziomy-agentowego-wytwarzania) napisałem, że walidacja zmienia się z bramki w pętlę, a policy-as-code staje się nieodzowne. No dobra, deko mięcha — rozłóżmy to na części: co konkretnie w deterministycznej warstwie platformy musi się zmienić, by agenci mogli generować zmiany seriami, bezpiecznie i bez zatkania systemu.

<div class="callout">
<strong>Teza</strong>
<p>Bezpieczeństwo agentów nie wynika z tego, że model jest mądry. Wynika z tego, że <em>każdy</em> artefakt — niezależnie od autora — musi przejść przez te same, maszynowo egzekwowane bramki, zanim ruszy dalej.</p>
</div>

## Walidacja przestaje być bramką, staje się pętlą

W świecie ludzkim walidacja to przystanek: deweloper składa PR, CI uruchamia testy, recenzent ogląda zmianę. Gdy agenci produkują PR-y równolegle, ten model się załamuje — pojedynczy checkpoint natychmiast staje się wąskim gardłem.

Rozwiązaniem jest pętla: gdy walidacja zawodzi, sygnał błędu wraca do agenta, który poprawia implementację i próbuje ponownie. Cykl powtarza się, aż artefakt spełni wymagania.

<figure>
<svg viewBox="0 0 720 210" role="img" aria-label="Pętla walidacji z feedbackiem: niepowodzenie wraca do agenta, a powtarzalne błędy poprawiają jego model działania">
  <g fill="none" stroke="currentColor" stroke-width="1.5">
    <rect x="24" y="78" width="96" height="44" rx="6"/>
    <rect x="160" y="78" width="70" height="44" rx="6"/>
    <rect x="266" y="78" width="236" height="44" rx="6"/>
    <rect x="556" y="78" width="140" height="44" rx="6"/>
  </g>
  <g stroke="currentColor" stroke-width="1.5">
    <line x1="120" y1="100" x2="154" y2="100"/>
    <line x1="230" y1="100" x2="260" y2="100"/>
    <line x1="502" y1="100" x2="550" y2="100"/>
  </g>
  <g fill="currentColor">
    <path d="M154 96 L160 100 L154 104 Z"/>
    <path d="M260 96 L266 100 L260 104 Z"/>
    <path d="M550 96 L556 100 L550 104 Z"/>
  </g>
  <path d="M384 78 V36 H72 V72" fill="none" stroke="var(--color-rust)" stroke-width="1.5"/>
  <path d="M68 72 L72 78 L76 72 Z" fill="var(--color-rust)"/>
  <rect x="250" y="158" width="280" height="30" rx="15" fill="none" stroke="var(--color-muted)" stroke-width="1.2" stroke-dasharray="4 4"/>
  <path d="M384 122 V158" fill="none" stroke="var(--color-muted)" stroke-width="1.2" stroke-dasharray="4 4"/>
  <path d="M380 152 L384 158 L388 152 Z" fill="var(--color-muted)"/>
  <path d="M250 173 H72 V126" fill="none" stroke="var(--color-muted)" stroke-width="1.2" stroke-dasharray="4 4"/>
  <path d="M68 130 L72 124 L76 130 Z" fill="var(--color-muted)"/>
  <g font-family="'Space Grotesk', system-ui, sans-serif" font-size="13" fill="currentColor" text-anchor="middle">
    <text x="72" y="104">agent</text>
    <text x="195" y="104">PR</text>
    <text x="384" y="104">CI: testy · skany · polityki</text>
    <text x="626" y="104">kandydat gotowy</text>
  </g>
  <g font-family="'Space Mono', monospace" font-size="11">
    <text x="228" y="28" text-anchor="middle" fill="var(--color-rust)">fail → opis błędu wraca do agenta</text>
    <text x="527" y="92" text-anchor="middle" fill="var(--color-muted)">pass</text>
    <text x="390" y="177" text-anchor="middle" fill="var(--color-muted)" font-size="10">popraw model agenta: kontekst · reguły · testy</text>
  </g>
</svg>
<figcaption>Pętla walidacji — niepowodzenie wraca do agenta (ponów), a powtarzalne błędy poprawiają jego model działania, by ta sama klasa błędu nie wracała.</figcaption>
</figure>

Aspiracja jest zaskakująca: **faza weryfikacji powinna stać się nudna**. Zanim zmiana dotrze do walidacji, powinna niemal zawsze przechodzić. Jeśli nie przechodzi, to sygnał, że trzeba poprawić *model działania agenta* (kontekst, reguły, oczekiwania testowe), a nie tylko tę jedną zmianę. Walidacja przestaje być pasywną siatką bezpieczeństwa, a staje się mechanizmem, który wypycha rozwiązywanie defektów w górę procesu.

## Trzy konsekwencje pętli walidacji

**1. Presja na pojemność CI.** Agenci iterują znacznie agresywniej niż ludzie — powtarzają, aż przejdzie, i uruchamiają szersze zestawy weryfikacji. To oznacza więcej przebiegów pipeline'u, więcej środowisk efemerycznych i potencjalnie dramatycznie wyższe zużycie compute. Źle zaprojektowane CI potrafi rosnąć kosztowo szybciej niż przyrost produktywności. Stąd waga cache'owania, przenośnych kroków (np. [Dagger](/katalog/dagger)) i szybkich, jednorazowych klastrów ([kind](/katalog/kind)) zamiast ciężkich, długowiecznych środowisk.

**2. Weryfikacja musi wyjść poza testy jednostkowe.** Same unit testy nie zastąpią osądu recenzenta. Organizacje poszerzają deterministyczną weryfikację o scenariusze e2e, testy wydajności, analizę zależności i licencji oraz kontrolę integralności środowiska. Na froncie często dominuje weryfikacja zachowania (deploy preview, a nawet agenci „usability" robiący zrzuty/nagrania); backend wymaga twardszych dowodów (scenariusze, regresje czasu startu, polityki bezpieczeństwa).

**3. Bezpieczeństwo i polityki muszą być automatyczne.** Przy wolumenie zmian generowanych maszynowo ręczny przegląd bezpieczeństwa nie skaluje się. Skany podatności, wykrywanie sekretów, kontrola zgodności — wszystko to musi być częścią pętli walidacji, nie audytem po wdrożeniu.

## Policy-as-code jako deterministyczna bramka

Najważniejsza zasada: polityki na artefaktach IaC (plany [Terraform](/katalog/terraform)/[OpenTofu](/katalog/opentofu), manifesty [Kubernetes](/katalog/kubernetes), charty [Helm](/katalog/helm)) muszą działać jako **bramki w CI**, a nie audyty po fakcie. Narzędzia jak [OPA](/katalog/open-policy-agent), [Kyverno](/katalog/kyverno) czy [Checkov](/katalog/checkov) przestają być dodatkiem, a stają się obowiązkowym krokiem.

Przykład — test konfiguracji przez [Conftest](/katalog/conftest) (silnik OPA/Rego) jako krok pipeline:

```rego
# policy/deployment.rego
package main

deny contains msg if {
  input.kind == "Deployment"
  not input.spec.template.spec.securityContext.runAsNonRoot
  msg := "kontener musi działać jako non-root (runAsNonRoot: true)"
}
```

```yaml
# krok w CI (Gitea Actions / dowolne) — twarda bramka
- run: conftest test k8s/ --policy policy/
- run: checkov -d infra --soft-fail-on LOW
- run: trivy config infra --exit-code 1 --severity HIGH,CRITICAL
```

Dlaczego to akurat teraz „non-negotiable"? Bo skodyfikowane, maszynowo egzekwowalne reguły są warunkiem bezpiecznego przejścia z Poziomu 2 na 3: **jakość warstwy polityk wprost wyznacza, ile autonomii możesz bezpiecznie przyznać agentom.** W klastrze te same reguły można egzekwować w czasie wdrożenia przez [OPA Gatekeeper](/katalog/gatekeeper) lub [Kyverno](/katalog/kyverno) (admission control; Kyverno trzyma polityki w YAML, bez osobnego języka), a statycznie w CI przez [Conftest](/katalog/conftest) — ta sama intencja, różne warstwy.

Dodatkowy niuans kolejności: AI-asystowany przegląd kodu działa najlepiej **wcześnie** w pętli — automatyczny recenzent generuje uwagi, zanim spojrzy na to człowiek, a agent od razu je wchłania. Do walidacji trafia więc artefakt, w którym usterki mechaniczne są już rozwiązane.

## Środowiska efemeryczne: izolacja i dowód

Skoro wiele zmian biegnie równolegle, nie mogą sobie nawzajem deptać po środowiskach. Stąd **środowiska efemeryczne** — tworzone na żądanie, jednorazowe, izolowane. Na froncie służą jako deploy preview (recenzent ogląda działającą funkcję, nie kod); na backendzie jako miejsce, gdzie biegną scenariusze e2e.

```yaml
# efemeryczny klaster do walidacji w CI, kasowany po teście
- run: kind create cluster --name pr-${PR_NUMBER}
- run: kubectl apply -k overlays/ci
- run: npm run test:e2e
- run: kind delete cluster --name pr-${PR_NUMBER}
```

Klucz: środowisko jest dowodem. Walidacja ma wyprodukować dowód na tyle mocny, by zastąpić ręczne czytanie diffów — a efemeryczny, czysty klaster ([kind](/katalog/kind), a dla cięższych przypadków [k3s](/katalog/k3s)) daje powtarzalny punkt odniesienia.

## Tożsamość nie-ludzka i granice działania

Gdy agent „wysyłany jest do pracy", musi działać z własną, ograniczoną tożsamością — nie z poświadczeniami człowieka. To warunek audytu („kto/co to zrobił") i ograniczenia promienia rażenia. Wzorce:

- **Tożsamość nie-ludzka** dla agenta z wąskim zakresem uprawnień (co wolno dotknąć), brokerowana przez niezależny IdP (np. [Dex](/katalog/dex)).
- **Krótkożyciowe poświadczenia** zamiast statycznych sekretów — pobierane dynamicznie z [Vault](/katalog/vault)/[OpenBao](/katalog/openbao), nigdy zaszyte w repo.
- **Izolacja workspace** dla równoległych przebiegów, by nie kolidowały.
- **Provenance** artefaktów — podpisywanie wydań/commitów (np. bezkluczowo przez [gitsign](/katalog/gitsign)), by dało się udowodnić, skąd pochodzi zmiana.

Rozwijamy te wzorce w artykule [Security Plane](/blog/security-plane-sekrety-tozsamosc-policy); tu istotne jest jedno: bez tożsamości nie-ludzkiej autonomia agentów jest nieaudytowalna, a więc nie do utrzymania w organizacji pod nadzorem.

## Mapowanie na pętlę OODA

Wszystko to wraca do pętli z [wprowadzenia](/blog/platform-engineering-normalizacja-pracy). Deterministyczny szkielet nie spowalnia pętli — on pozwala ją *bezpiecznie* przyspieszyć: polityki i walidacja to „orientacja" (wspólny model, co wolno), środowiska efemeryczne to tani, powtarzalny „test działania", a obserwowalność i audyt domykają sprzężenie. Im mocniejszy szkielet, tym ciaśniejszą pętlę można powierzyć maszynie.

## Podsumowanie

Deterministyczny szkielet to nie biurokracja spowalniająca agentów — to system bezpieczeństwa, który w ogóle umożliwia ich pracę na skalę. Walidacja-pętla, policy-as-code jako bramka, środowiska efemeryczne i tożsamość nie-ludzka zamieniają nieprzewidywalną moc modeli w przewidywalny, audytowalny wynik. To również dokładnie ta warstwa, której domagają się regulacje — [DORA](https://eur-lex.europa.eu/eli/reg/2022/2554/oj) i [AI Act](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai) — co rozwijam w częściach o [DORA w praktyce](/blog/dora-w-praktyce-platformy) i AI Act. Bez tej warstwy cała reszta to życzenie, nie system — i żaden model tego za Ciebie nie załata.

---


# Cztery poziomy agentowego wytwarzania oprogramowania

URL: https://eiac.dev/blog/cztery-poziomy-agentowego-wytwarzania
Filar: SDLC / Policy-as-Code
Data: 2026-03-17
Tagi: platform-engineering, agents, adp, value-stream, ai
Skrót: Dojrzałość agentowa to nie ilość AI, lecz zmiana, kto inicjuje pracę. Poziomy 0–4, model paths-to-outcomes i to, jak walidacja zamienia się w pętlę.

W poprzedniej części ([Od IDP do ADP](/blog/od-idp-do-adp)) ustaliłem, że przewagą nie jest model, lecz deterministyczny szkielet platformy. Ale „agentowość" to nie przełącznik wł./wył. — i tu robi się ciekawie. To **kontinuum dojrzałości**, w którym zmienia się jedno: kto inicjuje pracę i jak głęboko platforma domyka pętlę bez człowieka. Rozłóżmy je na pięć poziomów (0–4), używając modelu „paths-to-outcomes".

<div class="callout">
<strong>Klucz</strong>
<p>Poziomy różnią się nie liczbą użytego AI, lecz stopniem zaangażowania człowieka: <em>is → in → on → orchestrator → poza pętlą</em>. Im niżej możesz bezpiecznie zejść, tym wyższa przepustowość — ale „bezpiecznie" zależy od jakości platformy.</p>
</div>

## Model: ścieżki w strumieniu wartości

Niezależnie od narzędzi, strumień wartości „dostarcz funkcję" składa się z powtarzalnych ścieżek:

| Ścieżka | Typowe wejście | Wyjście |
|---|---|---|
| Zdobądź kontekst | ticket, issue, zgłoszenie | kontekst do pracy |
| Zmień (implement) | tworzenie kodu | kandydacka zmiana / commit |
| Zweryfikuj (validate) | zmiana / PR | zweryfikowany artefakt lub błąd |
| Promuj (promote) | zweryfikowany artefakt | zatwierdzony do wdrożenia |
| Wdróż (deploy) | artefakt wydania | działający system |
| Obserwuj (observe) | sygnały runtime | telemetria, widoczność |
| Napraw (remediate) | alert | przywrócony stan |

Ta struktura jest stabilna — i to czyni ją użyteczną: pozwala rozmawiać o platformie niezależnie od konkretnego CI czy chmury. Poziomy agentowe to opis tego, jak te ścieżki się zmieniają.

## Poziom 0: człowiek jest pętlą

Punkt wyjścia: działający IDP, zero agentów. Człowiek pisze kod, a deterministyczna platforma wspiera wykonanie, wdrożenie i testy. Zysk rośnie liniowo, ograniczeniem jest przepustowość ludzi. To nie jest „poziom agentowy" — to fundament, który (jak pisaliśmy w [Od IDP do ADP](/blog/od-idp-do-adp)) jest tą samą pracą, co budowa ADP.

## Poziom 1: człowiek w pętli

Agent wchodzi do edytora jako asystent. Zmieniają się dwie ścieżki: **zdobądź kontekst** (agentowe wyszukiwanie, wyjaśnianie komponentów) i **zmień** (generowanie kodu z promptu). Reszta systemu jest nietknięta — kod nadal idzie przez PR, CI dalej waliduje, człowiek akceptuje lub odrzuca każdą propozycję.

To lokalne usprawnienie, nie zmiana strukturalna. Zysk jest realny, ale ograniczony — bo wąskim gardłem pozostaje przepustowość ludzkiego przeglądu. Wartość tego poziomu: osłania przed halucynacją (człowiek filtruje) i jest łatwy do wdrożenia.

## Poziom 2: człowiek na pętli

Najbardziej fundamentalny przeskok. Agent przestaje być prywatnym narzędziem w edytorze, a staje się **uczestnikiem strumienia wartości**. Człowiek nadal „wysyła agenta" do pracy (to on jest wyzwalaczem i ponosi odpowiedzialność), ale wiele zadań biegnie równolegle w tle.

Pojawia się **nowa ścieżka: „dispatch work to agents"** — warstwa, która zamienia ludzkie zlecenia w wykonywalne zadania agentowe z odpowiednim kontekstem, tożsamością i granicami. Typowe wejścia to nie „wymagania" w sensie SDLC, lecz zlecenia: „zbadaj ten alert z Sentry", „zrób pierwszą wersję z tego ticketu", „oskryptuj komponent z tego zrzutu ekranu". Jeden człowiek może uruchomić kilka agentów naraz, a potem zdecydować, co awansować.

Drugą, najbardziej niedocenianą zmianą jest to, że **walidacja staje się pętlą**:

<figure>
<svg viewBox="0 0 720 170" role="img" aria-label="Walidacja jako pętla: agent, PR, CI; przy niepowodzeniu sygnał wraca do agenta, przy sukcesie powstaje kandydat">
  <g fill="none" stroke="currentColor" stroke-width="1.5">
    <rect x="24" y="74" width="96" height="44" rx="6"/>
    <rect x="160" y="74" width="76" height="44" rx="6"/>
    <rect x="276" y="74" width="232" height="44" rx="6"/>
    <rect x="560" y="74" width="136" height="44" rx="6"/>
  </g>
  <g stroke="currentColor" stroke-width="1.5">
    <line x1="120" y1="96" x2="154" y2="96"/>
    <line x1="236" y1="96" x2="270" y2="96"/>
    <line x1="508" y1="96" x2="554" y2="96"/>
  </g>
  <g fill="currentColor">
    <path d="M154 92 L160 96 L154 100 Z"/>
    <path d="M270 92 L276 96 L270 100 Z"/>
    <path d="M554 92 L560 96 L554 100 Z"/>
  </g>
  <path d="M392 74 V34 H72 V68" fill="none" stroke="var(--color-rust)" stroke-width="1.5"/>
  <path d="M68 68 L72 74 L76 68 Z" fill="var(--color-rust)"/>
  <g font-family="'Space Grotesk', system-ui, sans-serif" font-size="13" fill="currentColor" text-anchor="middle">
    <text x="72" y="100">agent</text>
    <text x="198" y="100">PR</text>
    <text x="392" y="100">CI: testy · skany · polityki</text>
    <text x="628" y="100">kandydat gotowy</text>
  </g>
  <g font-family="'Space Mono', monospace" font-size="11">
    <text x="232" y="26" text-anchor="middle" fill="var(--color-rust)">fail → poprawka, ponów</text>
    <text x="534" y="88" text-anchor="middle" fill="var(--color-muted)">pass</text>
  </g>
</svg>
<figcaption>Walidacja jako pętla — przy niepowodzeniu sygnał wraca do agenta, który poprawia i ponawia.</figcaption>
</figure>

Walidacja przestaje być bramką, przez którą przechodzi człowiek, a staje się przemysłowym sprzężeniem zwrotnym: agent powtarza próby, aż artefakt spełni wymagania platformy. To rodzi trzy konsekwencje, którym poświęcamy osobny artykuł ([Deterministyczny szkielet platformy agentowej](/blog/deterministyczny-szkielet-adp)): presję na pojemność CI, konieczność poszerzenia weryfikacji poza testy jednostkowe, oraz **policy-as-code jako nieodzowną, automatyczną bramkę** (np. [OPA](/katalog/open-policy-agent)/[Conftest](/katalog/conftest), [Checkov](/katalog/checkov), [Trivy](/katalog/trivy)).

Promocja też się zmienia: człowiek nie czyta każdego diffa, lecz **weryfikuje zachowanie** (deploy preview, dowody z testów) i priorytetyzuje, co scalić. Na froncie często wystarczy podgląd w środowisku efemerycznym; backend wymaga twardszych, deterministycznych dowodów (scenariusze e2e, testy wydajności, polityki bezpieczeństwa).

## Poziom 3: człowiek jako orkiestrator

Platforma zaczyna działać jako **ciągła warstwa wykonawcza w tle**. Praca nie wchodzi już tylko przez zlecenia człowieka — to platforma generuje ją z zaobserwowanych wzorców: nawracających anomalii, aktualizacji zależności, regresji wydajności, zaległości wykrytych analizą.

Ścieżka „dispatch" rozrasta się w warstwę koordynacji całego ekosystemu agentów: harmonogramowanie, koordynacja wielu agentów na powiązanych obszarach, **wykrywanie konfliktów** gdy zmiany się nakładają. Ścieżka „obserwuj" staje się głównym źródłem sygnałów napędzających pracę. Przegląd człowieka staje się **wyjątkowy** — wkracza, gdy walidacja daje wynik niejednoznaczny lub zmiana jest wysokiego ryzyka.

Pojawia się **promocja oparta na regule** — klasyfikacja ryzyka decyduje, co może iść automatycznie:

```yaml
# polityka promocji oparta na ryzyku (pseudo-konfiguracja)
promotion:
  auto:
    when:
      - change_class: ["dependency-patch", "config-tweak", "docs"]
      - validation: all-green
      - blast_radius: low
  human_review:
    when:
      - change_class: ["schema-migration", "iam", "public-api"]
      - blast_radius: ["medium", "high"]
```

Człowiek przestaje zatwierdzać pojedyncze zmiany — zaczyna **projektować reguły**, według których zmiany awansują. Ograniczenie przesuwa się z przepustowości przeglądu na dojrzałość architektury i ekonomię tokenów. Co istotne: bardzo niewiele organizacji jest dziś w pełni na poziomie 3 — częściej dla części frontendowej.

## Poziom 4: pełna autonomia (zarys)

Logiczny kraniec trajektorii. Agenci **nie czekają już na zlecenia** — inicjują pracę w reakcji na sygnały środowiska (telemetria, zachowanie klientów, anomalie kosztów, alerty bezpieczeństwa), w granicach zdefiniowanych przez platformę. Ścieżka „napraw" staje się **samonaprawcza**: klasyfikacja incydentu dopasowuje znany wzorzec/playbook, a auto-remediacja wykonuje naprawę lub rollback bez człowieka; ludzie zajmują się tylko nowymi lub wysokoryzykownymi przypadkami, a każda naprawa poszerza bibliotekę wzorców.

To, co Poziom 4 odblokowuje, jest jakościowo nowe: ciągły refactoring na dużą skalę, proaktywna remediacja CVE i dryfu zgodności, adaptacja do popytu, a przede wszystkim **samodoskonaląca się walidacja** — system analizuje własne wzorce porażek i aktualizuje kontekst/testy/reguły, by ta sama klasa błędu nie docierała ponownie do walidacji.

Trzeba uczciwie powiedzieć: udokumentowanych wdrożeń Poziomu 4 jest dziś bardzo mało. Większość zespołów jest między 1 a 2, niektóre dotykają 3. Poziom 4 to mniej „praktyka branżowa", a bardziej kierunek — i zestaw ograniczeń architektonicznych, które trzeba spełnić, by autonomia była bezpieczna.

## Jak zmieniają się ścieżki, poziom po poziomie

| Ścieżka | L1 | L2 | L3 | L4 |
|---|---|---|---|---|
| Zdobądź kontekst | wspomagana | dla agentów | ciągła | autonomiczna |
| Zmień | wspomagana | wykonywana przez agenta | bez inicjacji człowieka | z sygnałów środowiska |
| Zweryfikuj | bramka | **pętla** | wysoki wolumen | krytyczna warstwa kontroli |
| Promuj | ręczna | weryfikacja zachowania | reguła (low-risk) | automatyczna |
| Obserwuj | jak L0 | źródło zleceń | główne źródło sygnału | warstwa sensoryczna |
| Napraw | ręczna | kierowana przez człowieka | częściowo auto | samonaprawcza |
| Dispatch | — | **nowa** | koordynacja ekosystemu | inicjacja ze środowiska |

## Co to znaczy w praktyce

Awans o poziom to nie „włącz więcej AI", lecz **inwestycja w konkretną zdolność platformy**: z L1 na L2 — kontekst dla agentów, tożsamość nie-ludzka, walidacja jako pętla, polityki jako kod; z L2 na L3 — harmonogramowanie, wykrywanie konfliktów, klasyfikacja ryzyka i auto-promocja; z L3 na L4 — samonaprawa i samodoskonalenie walidacji. Każdy z tych elementów to deterministyczny mechanizm — i właśnie one, nie modele, decydują, jak daleko możesz bezpiecznie zejść z człowiekiem z pętli.

## Podsumowanie

Cztery poziomy to mapa, nie drabina do przebiegnięcia na siłę. Pokazują, że dojrzałość agentowa rośnie wraz z dojrzałością deterministycznego szkieletu: im lepsze polityki, walidacja i obserwowalność, tym więcej pętli platforma może domknąć bezpiecznie. W następnej części schodzę do tego szkieletu — pokazuję, jak walidacja-pętla i policy-as-code czynią agentów bezpiecznymi w praktyce. Ustaw sobie szczerze, na którym poziomie jesteś dziś — bo to on wyznacza, ile autonomii możesz bezpiecznie oddać.

---


# Od IDP do ADP: platforma w erze agentów

URL: https://eiac.dev/blog/od-idp-do-adp
Filar: SDLC / Policy-as-Code
Data: 2026-03-11
Tagi: platform-engineering, adp, idp, agents, ai
Skrót: Gdy część pracy w pętli przejmuje agent, platforma musi się zmienić — z IDP w ADP. Dlaczego przewaga nie leży w lepszym modelu, lecz w systemie produkcyjnym, który go ujarzmia.

We [wprowadzeniu do serii](/blog/platform-engineering-normalizacja-pracy) postawiłem tezę, że platform engineering to skracanie organizacyjnej [pętli OODA](https://pl.wikipedia.org/wiki/OODA) — uspójnianie i przyspieszanie drogi od obserwacji do działania. Zobaczmy teraz, co się z tą pętlą dzieje, gdy do gry wchodzą agenci AI: większość pracy przestaje wykonywać człowiek przy klawiaturze, a zaczyna ją wykonywać platforma. To wymusza zmianę samej platformy — z **IDP** (Internal Developer Platform) w **ADP** (Agentic Development Platform).

<div class="callout">
<strong>Teza</strong>
<p>To nie wyścig o najlepszy model. Modele to towar o zbieżnych możliwościach. Różnicą jest <em>system produkcyjny</em>, który ujarzmia inteligencję i utrzymuje ją w ryzach — czyli deterministyczny szkielet platformy.</p>
</div>

## Dlaczego model to nie wąskie gardło

Wydajność modeli na zadaniach inżynierskich (mierzona np. na [SWE-bench](https://www.swebench.com/)) przeszła w ostatnich latach od bliskiej zeru do poziomów porównywalnych z człowiekiem, i wciąż rośnie. Dostęp do mocnego modelu jest dziś kwestią klucza API, nie przewagi. Skoro tak, to przewaga nie może leżeć w „lepszym modelu" — bo ten ma każdy.

Z analiz nieudanych wdrożeń AI wyłania się powtarzalny wzorzec: w większości przypadków zawiodły **nie modele, lecz platforma** — brak guardrails, brak deterministycznych bramek, brak miejsca, w którym agent mógłby działać szybko i bezpiecznie. Organizacja, która „dokłada AI" na wierzch starego procesu, dostaje wszystkie wady probabilistyki (halucynacje, niespójność) przy znikomych korzyściach — i wnioskuje, że „to nie dla niej". To samospełniająca się pułapka.

Prawdziwy wyścig toczy się więc o coś innego: jak bardzo zrównoleglić i zautomatyzować pracę, nie tracąc kontroli. A to zależy od jakości platformy.

## Probabilistyczne spotyka deterministyczne

Architektura zdolna do bezpiecznej pracy z agentami musi połączyć dwa światy o przeciwnej naturze.

**Systemy probabilistyczne** — rozumują, generalizują i poprawiają się z kontekstem, ale są nieprzewidywalne:

- modele fundamentalne i agenci kodujący,
- frameworki koordynacji wielu agentów,
- warstwy oceny i ewaluacji zachowań (model-evaluating, behavioral evaluation).

**Systemy deterministyczne** — przewidywalne, powtarzalne, audytowalne:

- orkiestracja platformy (bezpieczne tworzenie i zmiana zasobów),
- jawne granice zdolności i stabilne API,
- reprodukowalne pipeline'y CI/CD i **środowiska efemeryczne** do izolacji i weryfikacji,
- egzekwowanie polityk, tożsamość i RBAC,
- zarządzanie stanem, warstwy semantyczne nad danymi, weryfikacja zależności i licencji,
- obserwowalność i ślad audytowy.

IDP standaryzuje ścieżki dla ludzi. **ADP czyni te ścieżki wykonywalnymi przez agentów na dużą skalę — a docelowo pozwala agentom uruchamiać je samodzielnie.** To nie jest nowy zestaw narzędzi, lecz nowy kontrakt: deterministyczna część platformy staje się systemem bezpieczeństwa dla części probabilistycznej.

## Złote ścieżki dla ludzi to złote ścieżki dla agentów

Najważniejsza praktyczna obserwacja: ścieżki, które dziś budujesz dla developerów, to dokładnie te same ścieżki, które jutro będą wykonywać agenci. Model „paths-to-outcomes" z wprowadzenia (zdobądź kontekst → zmień → zweryfikuj → wypuść → obserwuj → napraw) nie znika — zmienia się tylko to, **kto** i **jak często** go przemierza.

Dlatego budowa solidnego IDP nie jest „warunkiem wstępnym" myślenia o agentach — to ta sama praca, widziana przez inną soczewkę. Jeśli ścieżka jest deklaratywna, idempotentna i weryfikowalna automatycznie, agent może po niej iść. Jeśli wymaga ręcznego klikania i wiedzy plemiennej, nie pójdzie po niej ani agent, ani nowy człowiek.

Przykład: ta sama bramka polityki (tu w Rego dla [Open Policy Agent](/katalog/open-policy-agent)) chroni zarówno zmianę od człowieka, jak i od agenta — bo działa na artefakcie, nie na intencji autora:

```rego
package eiac.deploy

# żaden obraz z tagiem :latest nie wejdzie na produkcję
deny contains msg if {
  input.kind == "Deployment"
  some c in input.spec.template.spec.containers
  endswith(c.image, ":latest")
  msg := sprintf("obraz %q ma tag :latest", [c.image])
}
```

Bramka nie pyta „czy to napisał człowiek?". Pyta „czy artefakt spełnia regułę?". To właśnie czyni ją bezpieczną przy wolumenie zmian generowanych maszynowo.

## Co naprawdę się zmienia: pętla, nie narzędzia

Struktura platformy pozostaje, ale obciąża się inaczej. Trzy przesunięcia są kluczowe:

- **Walidacja z bramki staje się pętlą.** Gdy agent generuje zmiany seriami, weryfikacja nie może być pojedynczym przystankiem — staje się przemysłowym sprzężeniem zwrotnym, w którym agent powtarza próby aż przejdzie. Rozwijamy to w artykule [Deterministyczny szkielet platformy agentowej](/blog/deterministyczny-szkielet-adp).
- **Ograniczenie przesuwa się z „szybkości pisania" na „jakość weryfikacji".** Wąskim gardłem nie jest już, jak szybko ktoś pisze kod, lecz jak szybko i wiarygodnie platforma potrafi go sprawdzić.
- **Rola człowieka wędruje w górę** — od pisania, przez przegląd, po definiowanie reguł i granic. Te poziomy zaangażowania to temat artykułu [Cztery poziomy agentowego wytwarzania](/blog/cztery-poziomy-agentowego-wytwarzania).

## Dlaczego to dotyczy też zgodności

Im więcej pętli domyka maszyna, tym ważniejsze stają się dwie rzeczy, które w świecie czysto ludzkim były „miłe, ale opcjonalne": **nadzór** i **ślad audytowy**. To nie przypadek, że dokładnie tego wymagają regulacje — [DORA](https://eur-lex.europa.eu/eli/reg/2022/2554/oj) (odporność operacyjna, udowadnialne procesy) i [AI Act](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai) (nadzór człowieka, logowanie, transparentność). Deterministyczny szkielet ADP — polityki jako kod, audyt, RBAC, środowiska efemeryczne — jest tym samym, co spełnia te wymogi. Wrócimy do tego w częściach poświęconych [DORA](/blog/dora-w-praktyce-platformy) i AI Act.

## Podsumowanie

Przejście z IDP do ADP nie polega na „dodaniu AI". Polega na wzmocnieniu deterministycznej części platformy tak, by mogła bezpiecznie napędzać część probabilistyczną. Modele są towarem; przewagą jest system produkcyjny, który zamienia ich nieprzewidywalną moc w przewidywalny wynik. W kolejnej części rozkładam ten przeskok na cztery konkretne poziomy dojrzałości — od człowieka piszącego kod po platformę, która sama domyka pętlę. Zapraszam do maszynowni, tam robi się konkretnie.

---


# Platform engineering: normalizacja pracy w organizacji

URL: https://eiac.dev/blog/platform-engineering-normalizacja-pracy
Filar: SDLC / Policy-as-Code
Data: 2026-03-05
Tagi: platform-engineering, idp, golden-paths, dx, ooda, wprowadzenie
Skrót: Platform engineering to normalizacja pracy — kodowanie osądu raz i stosowanie go wszędzie. Wprowadzenie do serii: korzyści, koszty i moment, w którym platforma ma (lub nie ma) sensu.

Przepracowałem dość lat jako admin, potem developer, a teraz devops, żeby oglądać ten sam film w kółko: w każdej organizacji powtarza się ten sam zestaw czynności — zdobądź kontekst, zmień kod, zweryfikuj, wypuść, obserwuj, napraw. Im więcej zespołów i usług, tym częściej te same kroki robi się na dziesiątki nieco różnych sposobów: każdy zespół po swojemu konfiguruje CI, inaczej wdraża, inaczej trzyma sekrety. Ta różnorodność, początkowo niewinna, z czasem staje się podatkiem — od onboardingu, przez bezpieczeństwo, po czas od pomysłu do produkcji.

**Platform engineering to dyscyplina, która ten podatek likwiduje przez normalizację** — ujednolicenie i uproduktowienie sposobu, w jaki organizacja buduje, dostarcza i utrzymuje software. To wprowadzenie do serii, w której rozłożymy na czynniki pierwsze, dokąd ta dyscyplina zmierza: ku platformom agentowym i suwerennym, w cieniu regulacji UE.

<div class="callout">
<strong>W skrócie</strong>
<p>Platform engineering zamienia powtarzalne czynności inżynierskie w „złote ścieżki" (golden paths) — domyślne, samoobsługowe, bezpieczne drogi od kodu do produkcji. Korzyść to spójność i prędkość; koszt to budowa oraz utrzymanie samej platformy.</p>
</div>

## Czym jest platform engineering

Platform engineering to projektowanie i utrzymywanie wewnętrznej platformy (często nazywanej **IDP** — Internal Developer Platform) traktowanej jak produkt, którego klientami są inżynierowie organizacji. Zamiast pojedynczego zespołu walczącego z infrastrukturą przy każdym projekcie, wydzielony zespół platformowy dostarcza gotowe, wspierane „drogi", z których reszta korzysta samoobsługowo.

Dwie idee są tu kluczowe:

- **Platforma jako produkt** — ma użytkowników, roadmapę, wsparcie i metryki adopcji. Nie jest zbiorem skryptów „bo ktoś kiedyś napisał", lecz świadomie utrzymywanym narzędziem.
- **Redukcja obciążenia poznawczego** — deweloper nie musi znać dziesięciu chmurowych API, polityk bezpieczeństwa i niuansów wdrożeń, żeby wypuścić zmianę. Platforma chowa tę złożoność za prostym interfejsem.

W języku [Team Topologies](https://teamtopologies.com/): zespoły „stream-aligned" (dostarczające wartość) korzystają z usług zespołu platformowego, by zmniejszyć liczbę rzeczy, które muszą trzymać w głowie naraz.

## Normalizacja pracy: złote ścieżki

Sercem platform engineeringu jest **golden path** — utwardzona, domyślna droga zrobienia czegoś dobrze. „Chcesz nową usługę? Oto szablon: repo, pipeline, wdrożenie, monitoring i polityki bezpieczeństwa już skonfigurowane." Zamiast zaczynać od pustej kartki, zaczynasz od sprawdzonego standardu — a odstępstwa są możliwe, ale świadome.

Normalizacja działa na kilku poziomach jednocześnie:

- **Self-service zamiast ticketów** — portal lub CLI, w którym deweloper sam zamawia środowisko, bazę czy nową usługę, zamiast czekać na zgłoszenie do innego zespołu.
- **Everything-as-code** — infrastruktura, konfiguracja, polityki i pipeline'y jako wersjonowany kod w repozytorium, a nie ręczne klikanie w konsolach.
- **Spójne bramki jakości** — te same testy, skany bezpieczeństwa i reguły zgodności na każdej ścieżce, egzekwowane automatycznie.

Efekt: dwie różne usługi w organizacji powstają, wdrażają się i są monitorowane w ten sam, przewidywalny sposób. To właśnie jest „normalizacja pracy".

## Pętla OODA: dlaczego normalizacja daje przewagę

Żeby zrozumieć, *dlaczego* normalizacja przekłada się na realną przewagę, a nie tylko porządek, warto sięgnąć po model spoza IT — [pętlę OODA](https://pl.wikipedia.org/wiki/OODA). Opracował ją na przełomie lat 70. i 80. XX wieku John Boyd, pułkownik USAF, początkowo by wyjaśnić, czemu amerykańscy piloci wygrywali pojedynki powietrzne w Korei mimo teoretycznie nie lepszych maszyn. Odpowiedź: **szybciej domykali cykl decyzyjny niż przeciwnik**.

OODA to cztery przeplatające się — zwykle równoległe — fazy adaptacyjnego podejmowania decyzji:

- **Observe (Obserwacja)** — zbieranie danych o otoczeniu, w tym informacji zwrotnych z własnych wcześniejszych działań.
- **Orient (Orientacja)** — nałożenie obserwacji na model pojęciowy i synteza przesłanek do działania. Boyd uważał tę fazę za najważniejszą: ukształtowana przez doświadczenie, kulturę i nawyki, decyduje o jakości całego cyklu i o tym, jak szybko reagujemy „odruchowo".
- **Decide (Decyzja)** — wybór (lub odrzucenie) jednego z wariantów działania; świadomy albo rutynowy.
- **Act (Działanie)** — realizacja, która jest zarazem testem decyzji i modelu pojęciowego, a przez interakcję z otoczeniem — źródłem nowych obserwacji. Pętla się zamyka i zaczyna od nowa.

Kluczowa teza Boyda: kto **szybciej i celniej domyka swoją pętlę**, ten narzuca tempo — „działa wewnątrz cyklu OODA przeciwnika", zanim ten zdąży zareagować. Z czasem model wyszedł poza lotnictwo: trafił do doktryny US Marine Corps i wojny sieciocentrycznej, a dziś opisuje też organizacje adaptacyjne i uczące się, konkurujące na zmiennych rynkach przez szybkość, zakres, częstotliwość, precyzję, skuteczność i koszt zmiany.

I tu wraca platform engineering. Cykl życia zmiany w oprogramowaniu — *zdobądź kontekst → zmień → zweryfikuj → wypuść → obserwuj → napraw* — to w istocie organizacyjna pętla OODA. **Normalizacja pracy to celowe skracanie i synchronizowanie tej pętli:**

- złote ścieżki i self-service **skracają czas** od obserwacji do działania (mniej oczekiwania, mniej ręcznych kroków, mniej ticketów po drodze);
- everything-as-code i spójne bramki **poprawiają orientację** — dają wspólny, czytelny model tego, jak system działa i co wolno, więc cała organizacja „orientuje się" tak samo;
- standaryzacja **poszerza obszar decyzji odruchowych** — rutynowe zmiany (aktualizacje zależności, drobne poprawki) przechodzą domyślną drogą bez naradzania się za każdym razem;
- obserwowalność **domyka pętlę**, karmiąc kolejną iterację danymi z produkcji.

Organizacja bez platformy ma wolną i rozsynchronizowaną pętlę OODA: każdy zespół orientuje się po swojemu, a decyzje grzęzną w kolejkach zgłoszeń. Platforma sprawia, że ta sama pętla kręci się szybciej i spójniej w całej firmie — i to jest właściwy powód, dla którego w ogóle warto normalizować pracę.

> Ta sama optyka prowadzi wprost do reszty serii: cała ewolucja, którą opiszemy — od automatyzacji po agentów — to kolejne sposoby na **kompresję pętli OODA**, aż po moment, w którym jej fragmenty zaczyna domykać sama platforma, bez człowieka w środku.

## Z czego składa się platforma

Choć narzędzia bywają różne, struktura jest powtarzalna. Typowa platforma spina:

- **Hosting kodu i przeglądy** — np. [Gitea](/katalog/gitea) lub [GitLab](/katalog/gitlab) jako źródło prawdy.
- **CI/CD i orkiestracja wdrożeń** — pipeline'y (np. [Woodpecker](/katalog/woodpecker), [Dagger](/katalog/dagger)) i GitOps ([Argo CD](/katalog/argo-cd), [Flux](/katalog/flux)).
- **Infrastruktura jako kod** — [OpenTofu](/katalog/opentofu) lub [Terraform](/katalog/terraform), zwykle na [Kubernetes](/katalog/kubernetes).
- **Bezpieczeństwo i polityki** — sekrety ([SOPS](/katalog/sops), [Vault](/katalog/vault)) i policy-as-code ([OPA](/katalog/open-policy-agent)).
- **Portal i katalog usług** — np. [Backstage](/katalog/backstage), spinający to w „jedną szybę".

Gotowe platformy „w pudełku" (jak [Harness](/katalog/harness)) próbują dostarczyć większość z tego od razu; podejście składane daje więcej kontroli kosztem integracji. Niezależnie od wyboru — to wciąż te same cegiełki.

## Zalety

- **Spójność i przewidywalność** — wszystkie usługi działają wedle tych samych reguł; mniej „specjalnych przypadków" do utrzymania.
- **Szybszy onboarding** — nowa osoba lub nowy zespół rusza w dni, nie tygodnie, bo droga jest gotowa.
- **Mniej toilu i ticketów** — samoobsługa zdejmuje rutynę z zespołów infrastrukturalnych.
- **Bezpieczeństwo i zgodność „wbudowane"** — skany, polityki i audyt są częścią ścieżki, a nie dodatkiem na końcu.
- **Skalowalność organizacyjna** — platforma rośnie raz, korzystają z niej wszystkie zespoły; wiedza nie zależy od pojedynczych osób.
- **Lepsze „day-2"** — utrzymanie, aktualizacje i obserwowalność są zaprojektowane, nie improwizowane.

## Wady i koszty

- **Wysoki koszt początkowy** — zbudowanie sensownej platformy to miesiące pracy, zanim pojawi się zwrot.
- **Potrzebny dedykowany zespół** — platforma bez właściciela degraduje się do zbioru porzuconych skryptów.
- **Ryzyko „złotej klatki"** — zbyt sztywne ścieżki frustrują zespoły o nietypowych potrzebach; bez „escape hatchy" platforma staje się hamulcem.
- **Over-engineering** — łatwo zbudować rozbudowaną platformę dla problemu, którego organizacja jeszcze nie ma.
- **Produkt, który nikt nie używa** — jeśli platformy nie traktuje się jak produktu (badanie potrzeb, adopcja, wsparcie), powstaje narzędzie omijane przez zespoły.
- **Przeciekająca abstrakcja** — gdy coś się psuje pod spodem, deweloper i tak musi zrozumieć warstwę, którą platforma miała ukryć.

## Kiedy to nie ma sensu

Platform engineering to inwestycja, która zwraca się przy skali i powtarzalności. Bywa przedwczesna, gdy:

- masz **jeden, dwa zespoły i kilka usług** — narzut platformy przewyższy korzyść;
- jesteś **wczesnym startupem**, gdzie produkt i kierunek zmieniają się co tydzień — standaryzujesz coś, co jutro wyrzucisz;
- **powtarzalność jest niska** — robisz rzeczy na tyle różne, że nie ma czego normalizować;
- **zarządzany PaaS w zupełności wystarcza** — jeśli gotowa usługa pokrywa Twoje potrzeby, budowanie własnej platformy to wyważanie otwartych drzwi.

W takich sytuacjach lepszy jest pragmatyzm: rozsądny zarządzany hosting, kilka konwencji i minimum automatyki. Platformę buduje się, gdy *ból powtarzalności* zaczyna realnie kosztować.

## Kiedy ma sens

I odwrotnie — sygnały, że czas na platformę:

- **wiele zespołów i usług**, które rozjeżdżają się w sposobach pracy;
- **powtarzający się toil** (te same tickety, te same konfiguracje w kółko);
- **presja regulacyjna** (audyt, zgodność, bezpieczeństwo), którą trudno spełniać ad hoc;
- potrzeba **skrócenia czasu od pomysłu do produkcji** przy rosnącej organizacji.

> Reguła kciuka: buduj platformę, gdy koszt braku standardu (chaos, czas, ryzyko) zaczyna przewyższać koszt jego utrzymania. Ani wcześniej, ani — co gorsza — dużo później.

## Co dalej w tej serii

To wprowadzenie zakreśla fundament. W kolejnych częściach pójdziemy w głąb dwóch wielkich kierunków, w których platform engineering ewoluuje:

- **Agentowość** — jak platforma musi się zmienić, by bezpiecznie zaprząc AI: [od IDP do platformy agentowej (ADP)](/blog/od-idp-do-adp), [cztery poziomy dojrzałości agentowego wytwarzania](/blog/cztery-poziomy-agentowego-wytwarzania), oraz [deterministyczny szkielet](/blog/deterministyczny-szkielet-adp) (walidacja jako pętla, policy-as-code), który czyni agentów bezpiecznymi.
- **Suwerenność i zgodność** — platforma jako [„exit-by-design"](/blog/suwerenny-idp-exit-by-design), przenośność przez everything-as-code i GitOps, [otwartość a suwerenność](/blog/open-source-a-suwerennosc) oraz [suwerenne AI na modelach open-weight](/blog/suwerenne-ai-open-weight), a do tego [Security Plane](/blog/security-plane-sekrety-tozsamosc-policy) (tożsamość, sekrety, policy). Pokażemy też, jak regulacje UE — **[DORA](https://eur-lex.europa.eu/eli/reg/2022/2554/oj)** ([w praktyce platformy](/blog/dora-w-praktyce-platformy)) i **[AI Act](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai)** ([a agentowy SDLC](/blog/ai-act-a-agentowy-sdlc)) — wprost kształtują architekturę: od testowalnych strategii wyjścia po nadzór nad AI w cyklu wytwarzania.

Każdą z tych części osadzimy w praktyce i powiążemy z konkretnymi narzędziami z katalogu. Najpierw jednak warto zapamiętać jedno: platform engineering nie jest celem samym w sobie. Jest sposobem na to, by powtarzalna praca przestała być źródłem chaosu — a zaczęła być przewidywalną, wspólną drogą.

## Podsumowanie

Platform engineering normalizuje wytwarzanie oprogramowania: zamienia rozproszone, ręczne czynności w spójne, samoobsługowe złote ścieżki utrzymywane jak produkt. Daje spójność, prędkość i wbudowane bezpieczeństwo — kosztem realnej inwestycji w budowę i utrzymanie platformy oraz ryzyka nadmiaru. Nie każda organizacja go potrzebuje: przy małej skali i niskiej powtarzalności bywa przerostem formy nad treścią. Kluczem jest trzeźwa ocena, po której stronie tej granicy się znajdujesz — i właśnie od tej oceny zaczyna się cała seria. Jeśli wyjdzie Ci „jeszcze nie teraz" — spoko, to też jest dobra odpowiedź. A jeśli „tak", to reszta serii jest właśnie dla Ciebie.

---


# Design-as-Code: tokeny jako standard UI w platformie agentowej

URL: https://eiac.dev/blog/design-as-code-tokeny-od-zera
Filar: Design-as-Code
Data: 2026-02-27
Tagi: tokeny, design-system, css, adp, design-as-code, human-in-the-loop
Skrót: Tokeny zamieniają decyzje wizualne w jedno, audytowalne źródło prawdy. Dlaczego deterministyczną warstwę UI da się powierzyć agentowi, a UX zostaje przy człowieku w pętli.

Kiedy ostatnio kłóciłeś się z kimś, czy ten guzik jest `#A8482A`, czy jednak `#A94A2B`? Ja swoje odkłóciłem — i dlatego kolory, typografię i odstępy trzymam dziś nie w pliku graficznym, tylko jako **dane**. To z pozoru drobna zmiana nośnika ma daleko idącą konsekwencję: decyzja wizualna, która jest danymi, daje się wersjonować, walidować i egzekwować jak każdy inny kod. A skoro tak, to można ją powierzyć maszynie do *stosowania*, zostawiając człowiekowi to, czego maszyna nie udźwignie: osąd.

Ten artykuł rozwija tokeny od zera, a potem stawia tezę dla platformy agentowej (ADP, którą opisujemy [od IDP do ADP](/blog/od-idp-do-adp)): **design-as-code to warstwa, w której platforma egzekwuje standardy UI maszynowo — a UX zostaje przy człowieku w pętli.** Sprawdzimy, czy ten podział jest prawidłowy, pokażemy gdzie się rozmywa, przedstawimy konkurencyjną koncepcję (generative UI) i damy macierz wyboru ścieżki wdrożenia.

<div class="callout">
<strong>Teza</strong>
<p>Tokeny czynią <em>deterministyczną</em> warstwę UI (kolor, odstęp, typografia, promień) maszynowo egzekwowalną — agent wybiera z zamkniętego zbioru, a audyt w CI odrzuca odstępstwa. Warstwa <em>osądu</em> (architektura informacji, przepływy, dobór komponentu, intencja dostępności) pozostaje przy człowieku. Granica nie biegnie więc dokładnie między „UI" a „UX", lecz między tym, co deterministyczne, a tym, co wymaga osądu.</p>
</div>

## Dlaczego tokeny

Token to nazwana wartość — `color.link = #A8482A` — której używają jednocześnie strona, komponenty i materiały marketingowe. Zmiana w jednym miejscu propaguje się wszędzie. To samo, co Infrastructure-as-Code zrobił z serwerami — zamienił ręcznie strojone, nigdy nie identyczne maszyny w odtwarzalną, audytowalną konfigurację — tokeny robią z decyzjami wizualnymi: przestają być „bo ktoś tak kiedyś kliknął w Figmie", a stają się reprodukowalnym faktem w repo.

Wartość tokenów rośnie wprost proporcjonalnie do liczby miejsc, w których ta sama decyzja musi być spójna: light/dark, wiele marek, web/iOS/Android, aplikacja i landing. Bez tokenów każde z tych miejsc dryfuje niezależnie. Z tokenami dryf jest wykrywalny i odwracalny.

## Anatomia: trzy warstwy tokenów

Dojrzały zbiór tokenów to nie płaska lista, lecz trzy warstwy pośrednictwa — i to właśnie pośrednictwo daje siłę.

1. **Prymitywy (primitive / global)** — surowa paleta faktów: `--ds-rust-600: #A8482A`, `--ds-space-2: 8px`. Bez znaczenia, sama wartość.
2. **Tokeny semantyczne (alias)** — nadają prymitywom rolę: `--color-link: var(--ds-rust-600)`, `--space-inset-sm: var(--ds-space-2)`. To tu mieszka intencja („to jest kolor linku"), nie konkretny hex.
3. **Tokeny komponentu** — opcjonalna warstwa najbliżej UI: `--button-bg: var(--color-link)`. Komponent nigdy nie sięga do prymitywu ani do surowej wartości.

```json
// W3C DTCG: prymitywy i alias ($value/$type, alias przez {ścieżka})
{
  "ds": {
    "rust": { "600": { "$value": "#A8482A", "$type": "color" } },
    "space": { "2": { "$value": "8px", "$type": "dimension" } }
  },
  "color": {
    "link": { "$value": "{ds.rust.600}", "$type": "color" }
  },
  "space": {
    "inset-sm": { "$value": "{ds.space.2}", "$type": "dimension" }
  }
}
```

```css
/* Ta sama hierarchia w CSS — trzy warstwy pośrednictwa */
:root {
  --ds-rust-600: #A8482A;        /* prymityw  */
  --color-link: var(--ds-rust-600);   /* semantyka */
}
.button { color: var(--color-link); } /* komponent */
```

Pośrednictwo jest tym, co ratuje skórę: gdy marka zmienia odcień, podmieniasz **jeden** prymityw; gdy dochodzi dark mode czy druga marka, przepinasz **warstwę alias** — komponenty nie wiedzą o niczym. Płaska lista hexów takiej operacji nie przeżywa.

## Standard, nie dialekt: W3C DTCG

Do niedawna każde narzędzie miało własny format tokenów. To się zmieniło: [Design Tokens Format Module](https://www.designtokens.org/tr/) grupy [W3C Design Tokens Community Group](https://www.w3.org/community/design-tokens/) osiągnął [pierwszą stabilną wersję (2025.10)](https://www.w3.org/community/design-tokens/2025/10/28/design-tokens-specification-reaches-first-stable-version/) — wendor-neutralny JSON z polami `$value`/`$type`, aliasami, theming/multi-brand i nowoczesnymi przestrzeniami koloru (Display P3, Oklch, CSS Color 4). Trzymanie się standardu, zamiast formatu jednego dostawcy, to dokładnie ta sama zasada, którą stosujemy wobec [licencji i suwerenności](/blog/open-source-a-suwerennosc): unikasz zamknięcia.

Ekosystem narzędziowy zna już ten format. W praktyce sięga się po [Style Dictionary](/katalog/style-dictionary) (transpilacja jednego źródła do CSS/iOS/Android/Flutter), [Tokens Studio](/katalog/tokens-studio) (pomost Figma ↔ repo), a do dokumentacji i izolowanego rozwoju komponentów [Storybook](/katalog/storybook); całość projektowa może żyć w otwartym [Penpot](/katalog/penpot). Wspólny mianownik: **tokeny są źródłem, a kod i materiały są generowane** — nie odwrotnie.

## Tokeny jako guardrails dla agenta

Tu wchodzi platforma agentowa. Gdy interfejs pisze (lub współpisze) model, pojawia się problem, którego nie ma przy człowieku z dobrą pamięcią zespołową. Asystent kodujący nie *odpytuje* design systemu — on **generuje prawdopodobnie wyglądające wartości**. W jednej sesji potrafi podjąć 200–300 mikrodecyzji wizualnych (padding, odcień, promień), każda z osobna sensowna, a w sumie niespójna; a następna sesja nie pamięta poprzedniej i zgaduje od nowa ([opis problemu i metoda — Hardik Pandya](https://hvpandya.com/llm-design-systems)).

Trzy słabości modeli i ich tokenowe przeciwlekarstwa:

- **Fabrykuje wartości** → daj **zamkniętą warstwę tokenów**: agent wybiera z `var(--color-link)`, a nie wymyśla `#1D4ED8`. Nie ma „złego niebieskiego", bo jest tylko jeden.
- **Nie ma pamięci między sesjami** → daj **pliki spec w repo** (foundations + komponenty), które model czyta na starcie każdej sesji. Decyzję podjął człowiek raz; model ją *odczytuje*.
- **Nie czyta intencji ze źródła** → **audyt w CI**: skrypt skanuje CSS, a każda surowa wartość to błąd ze wskazaniem właściwego tokenu i `exit 1`. Czego nie da się scalić, tego nie ma.

```bash
# Bramka tokenowa w CI: zero surowych wartości w UI
$ npm run token-audit
src/components/Nav.css
  ✗ L42: zakodowany #1868DB → użyj var(--color-link)
  ✗ L78: surowy 12px w padding → użyj var(--space-inset-sm)
Errors: 2   # exit 1 → PR nie przechodzi
```

To jest dokładnie ten sam ruch, co [deterministyczny szkielet ADP](/blog/deterministyczny-szkielet-adp): nie ufamy modelowi „że będzie ładnie", tylko zamykamy go w polityce, która jest [policy-as-code](/blog/policy-as-code-dla-zespolow) i bramką w pipeline. Smak człowieka wchodzi raz — do tokenów i specyfikacji — a model stosuje go mechanicznie. Tokeny są więc dla UI tym, czym OPA dla wdrożeń: zamkniętym zbiorem dozwolonych decyzji.

<figure>
<svg viewBox="0 0 760 210" role="img" aria-label="Potok warstw tokenów: prymitywy do tokenów semantycznych do komponentów, na końcu bramka audytu w CI; człowiek ustawia tokeny raz, agent stosuje je mechanicznie.">
  <g fill="none" stroke="currentColor" stroke-width="1.5">
    <rect x="12" y="92" width="150" height="58" rx="6"/>
    <rect x="206" y="92" width="180" height="58" rx="6"/>
    <rect x="430" y="92" width="150" height="58" rx="6"/>
  </g>
  <rect x="624" y="92" width="124" height="58" rx="6" fill="none" stroke="var(--color-rust)" stroke-width="1.5"/>
  <g font-family="'Space Grotesk', system-ui, sans-serif" fill="currentColor" font-size="14" text-anchor="middle">
    <text x="87" y="116">Prymitywy</text>
    <text x="296" y="116">Tokeny semantyczne</text>
    <text x="505" y="116">Komponenty</text>
    <text x="686" y="116" fill="var(--color-rust)">Audyt w CI</text>
  </g>
  <g font-family="'Space Mono', monospace" fill="var(--color-muted)" font-size="11" text-anchor="middle">
    <text x="87" y="136">#A8482A · 8px</text>
    <text x="296" y="136">--color-link</text>
    <text x="505" y="136">var(--…)</text>
    <text x="686" y="136" fill="var(--color-rust)">exit 1 = stop</text>
  </g>
  <g fill="none" stroke="currentColor" stroke-width="1.5">
    <path d="M168 121 H200"/><path d="M392 121 H424"/><path d="M586 121 H618"/>
  </g>
  <g fill="currentColor">
    <path d="M200 121 l-7 -4 v8 z"/><path d="M424 121 l-7 -4 v8 z"/><path d="M618 121 l-7 -4 v8 z"/>
  </g>
  <path d="M87 64 V90" fill="none" stroke="var(--color-rust)" stroke-width="1.5" stroke-dasharray="4 3"/>
  <path d="M87 90 l-4 -7 h8 z" fill="var(--color-rust)"/>
  <text x="95" y="58" font-family="'Space Grotesk', system-ui, sans-serif" fill="var(--color-rust)" font-size="12">człowiek: smak raz →</text>
  <text x="430" y="184" font-family="'Space Grotesk', system-ui, sans-serif" fill="var(--color-muted)" font-size="12" text-anchor="middle">agent: stosuje mechanicznie, audyt pilnuje</text>
</svg>
<figcaption>Tokeny jako guardrails: człowiek ustawia warstwę raz, agent wybiera wyłącznie z zamkniętego zbioru, a audyt w CI odrzuca surowe wartości.</figcaption>
</figure>

## Gdzie kończy się automat: weryfikacja tezy

Czy założenie „UI maszynowo, UX przy człowieku" jest prawidłowe? Źródła w większości je potwierdzają — ale z istotną korektą, którą trzeba uczciwie postawić.

**Co potwierdza tezę.** Praktyka pokazuje, że gdy tylko zamkniesz warstwę tokenów i dodasz audyt, jakość wizualna dziesiątej sesji agenta dorównuje pierwszej — czyli deterministyczna część UI faktycznie się automatyzuje. Po drugiej stronie, UX z udziałem AI jest dziś opisywany jako wzorzec **human-in-the-loop**: AI proponuje, człowiek zatwierdza lub koryguje, bo to człowiek odpowiada za zaufanie, prowadzenie użytkownika i nadzór ([wzorzec HITL w UX](https://www.aufaitux.com/blog/human-in-the-loop-ux/)). AI ma być współpracownikiem, nie zamiennikiem projektanta.

**Gdzie teza wymaga korekty.** Linia podziału nie biegnie czysto między „UI" a „UX". Część UI to wciąż osąd: *który* komponent użyć (modal czy inline message), jak ułożyć architekturę informacji, jak brzmi mikrokopia, jaka jest *intencja* dostępności (nie samo `aria-`, lecz sensowny przepływ dla czytnika ekranu). Tego model nie wyczyta ze źródła — ta wiedza „mieszka w głowach projektantów" i musi zostać spisana albo dostarczona przez człowieka. Dlatego trafniejsza granica brzmi: **deterministyczne (tokeny, audyt, stany komponentu) → maszyna; wymagające osądu (IA, przepływy, dobór, kopia, intencja a11y) → człowiek w pętli.** Sam zgodny token nie gwarantuje dobrego doświadczenia — gwarantuje tylko spójność.

To rozróżnienie ma też wymiar regulacyjny: nadzór człowieka nad istotnymi decyzjami i ślad audytowy to nie tylko dobra praktyka UX, ale i kierunek, w którym idzie [AI Act](/blog/ai-act-a-agentowy-sdlc).

## Koncepcja alternatywna: generative UI

Powyższe zakłada **statyczny** interfejs: tokeny i komponenty są ustalone, a agent wypełnia je w czasie budowy. Istnieje jednak inna szkoła — **generative UI (GenUI)**: interfejs nie jest z góry zaprojektowany, lecz **składany przez AI w czasie działania**, dopasowany do kontekstu i intencji użytkownika ([przegląd GenUI](https://www.builder.io/blog/designing-generative-ui-in-an-agent-native-world)). Zamiast kodować każdy wariant ekranu, projektant ustawia *guardrails* — system prompt, model intencji i **kuratorowany katalog komponentów** — w których AT generuje UI na bieżąco.

Co istotne dla naszej tezy: nawet GenUI nie znosi standardów — przesuwa je. Nadal potrzebuje zamkniętego katalogu komponentów i tokenów jako budulca; zmienia się tylko *moment* składania (runtime zamiast build-time). Spotykane są trzy tryby, o rosnącym ryzyku:

- **Statyczny (parametryczny)** — AI wypełnia z góry zaprojektowane sloty danymi. Przewidywalny.
- **Deklaratywny (z rejestru)** — AI komponuje UI z zamkniętego rejestru komponentów. Zwykle najlepszy kompromis elastyczność/niezawodność.
- **W pełni generatywny** — AI emituje surowy HTML/CSS. Maksymalna elastyczność, maksymalne ryzyko (niespójność, halucynacje komponentów, bezpieczeństwo).

GenUI płaci za elastyczność znanymi kosztami: spójność (każde wygenerowanie może wyglądać inaczej), wydajność (generowanie trwa), bezpieczeństwo (dynamiczny kod) i halucynacje. Dlatego nie jest „następcą" design systemu, lecz innym punktem na tej samej osi — z tym samym fundamentem tokenów pod spodem.

## Wybierz ścieżkę wdrożenia

Nie ma jednej słusznej drogi — jest spektrum, a wybór zależy od tolerancji ryzyka, skali i tego, jak bardzo interfejs musi się adaptować do użytkownika. Trzy realne ścieżki:

| Ścieżka | Kiedy ma sens | Rola agenta | Człowiek w pętli | Główne ryzyko |
|---|---|---|---|---|
| **A. Statyczny design system + tokeny** | Większość produktów; potrzeba spójności i audytowalności | Pisze kod w granicach tokenów; audyt go pilnuje | Ustala tokeny/spec, projektuje IA i przepływy, recenzuje | Sztywność; „złota klatka" przy nietypowych potrzebach |
| **B. Deklaratywny GenUI (z rejestru)** | Interfejsy mocno kontekstowe (asystenci, dashboardy dopasowane do roli) | Składa UI z zamkniętego rejestru w runtime | Projektuje rejestr + guardrails, definiuje intencje, nadzoruje | Niespójność między wygenerowaniami; wydajność |
| **C. W pełni generatywny** | Eksperymenty, prototypy, wysoce spersonalizowane nisze | Emituje surowy markup w runtime | Definiuje twarde bariery bezpieczeństwa, waliduje wyjście | Halucynacje, bezpieczeństwo, brak powtarzalności |

Reguła kciuka: **zacznij od A** (tokeny + audyt to fundament, który i tak przyda się w B i C), sięgnij po **B**, gdy realnie potrzebujesz adaptacji do kontekstu, a **C** trzymaj za barierą człowieka w pętli i poza ścieżką krytyczną. We wszystkich trzech tokeny pozostają wspólnym mianownikiem — różni się tylko, *kiedy* i *jak swobodnie* agent z nich korzysta. Mapuje się to wprost na [cztery poziomy agentowego wytwarzania](/blog/cztery-poziomy-agentowego-wytwarzania): im wyżej autonomia, tym mocniejsze muszą być guardrails i tym wyraźniejszy punkt, w którym decyzję zatwierdza człowiek.

## Pierwszy plik

Niezależnie od ścieżki, start jest ten sam — jeden plik, który staje się źródłem prawdy:

```json
{
  "color": { "link": { "$value": "#A8482A", "$type": "color" } }
}
```

Stąd generujesz CSS variables, motywy i dokumentację — wszystko z repo, wszystko audytowalne, wszystko gotowe, by agent z tego korzystał, a nie zgadywał.

## Podsumowanie

Design-as-code zamienia decyzje wizualne w dane, a tokeny — w trójwarstwowy, standaryzowany ([W3C DTCG](https://www.designtokens.org/)) zbiór, który platforma agentowa potrafi egzekwować maszynowo: zamknięta warstwa tokenów, pliki spec i audyt w CI sprawiają, że agent stosuje smak człowieka, zamiast go wymyślać. Teza „UI dla maszyny, UX dla człowieka" jest w rdzeniu prawidłowa, ale precyzyjniej brzmi: **deterministyczne dla maszyny, wymagające osądu dla człowieka w pętli.** Alternatywa — generative UI — nie znosi tego fundamentu, tylko przesuwa moment składania na runtime. Wybór ścieżki (statyczny DS, deklaratywny GenUI, pełna generacja) należy do Ciebie i Twojej tolerancji ryzyka — ale każda z nich stoi na tym samym fundamencie tokenów. Zacznij od jednego pliku tokenów i audytu w CI, a potem sam zdecyduj, jak daleko wpuścisz agenta. Polecam się tym pobawić. :)

---


# Policy-as-Code dla zespołów: warstwa kontroli platformy

URL: https://eiac.dev/blog/policy-as-code-dla-zespolow
Filar: SDLC / Policy-as-Code
Data: 2026-02-23
Tagi: opa, rego, security, ci, policy-as-code, platform-engineering, adp, guardrails
Skrót: Polityka, której nie da się uruchomić, to dokument. Jak zamienić bezpieczeństwo i zgodność w warstwową płaszczyznę kontroli — od PR po admission — egzekwowaną jako guardrail, nie bramkarza.

Znasz to: w firmowej wiki leży „standard", którego nikt nie czyta, a na review i tak przechodzi PR łamiący zasadę — bo recenzent akurat jej nie pamiętał. Sam nieraz byłem tym recenzentem. Polityka, której nie da się uruchomić, to nie polityka, tylko dokument. **Policy-as-code (PaC)** zamienia ją w coś przeciwnego: regułę zapisaną jako kod, którą maszyna sprawdza przy każdej zmianie — deterministycznie, w tym samym miejscu co reszta pipeline'u, z wynikiem, który albo przepuszcza, albo zatrzymuje.

W [wprowadzeniu do serii](/blog/platform-engineering-normalizacja-pracy) postawiliśmy tezę, że platform engineering to normalizacja pracy — kodowanie osądu *raz* i stosowanie go *wszędzie*. Policy-as-code jest tej tezy najczystszym wcieleniem: zamiast debatować każdy przypadek z osobna, zespół platformowy zapisuje regułę i pozwala jej działać w kółko. Ten artykuł rozwija PaC od pojedynczej bramki w CI do **warstwowej płaszczyzny kontroli** całej platformy — i pokazuje, dlaczego to ona staje się fundamentem zarówno zgodności regulacyjnej, jak i bezpiecznej autonomii agentów.

<div class="callout">
<strong>Teza</strong>
<p>Policy-as-code to nie pojedynczy skan w CI, lecz <em>warstwa kontroli</em> rozłożona wzdłuż całego cyklu — od IDE i PR, przez build i plan IaC, po admission w klastrze. Egzekwowana automatycznie i blisko miejsca, gdzie pracuje inżynier, zamienia bezpieczeństwo i zgodność z bramkarza, który blokuje, w guardrail, który prowadzi — i daje gotowy ślad audytowy jako produkt uboczny.</p>
</div>

## Co właściwie znaczy „as code"

Sednem PaC jest **oddzielenie decyzji od egzekwowania**. Zamiast zaszywać logikę „czy wolno?" w każdej aplikacji i każdym skrypcie, opisujesz ją deklaratywnie w jednym miejscu, a silnik polityk odpowiada na pytania w czasie, gdy decyzja jest potrzebna. To daje trzy własności, których dokument nigdy nie miał:

- **Wersjonowanie** — polityka żyje w repo, ma historię zmian, autora i przegląd jak każdy inny kod.
- **Testowalność** — regułę można pokryć testami i uruchomić lokalnie, zanim trafi na produkcję.
- **Audytowalność** — każde uruchomienie zostawia ślad: co sprawdzono, na jakich danych i z jakim wynikiem.

To ta sama zmiana nośnika, którą opisaliśmy przy [tokenach designu](/blog/design-as-code-tokeny-od-zera): gdy reguła staje się danymi, przestaje zależeć od ludzkiej pamięci, a zaczyna od pipeline'u.

## OPA i Rego: uniwersalny silnik

[Open Policy Agent](/katalog/open-policy-agent) (OPA) to ogólnego przeznaczenia silnik polityk i [projekt CNCF na poziomie „graduated"](https://www.cncf.io/projects/) — czyli najwyższym poziomie dojrzałości. Jego siła to uniwersalność: jednym językiem opiszesz reguły dla Kubernetes, planu [Terraform/OpenTofu](/blog/suwerenny-idp-exit-by-design), API mikroserwisu czy pipeline'u CI. OPA nie wie nic o domenie — dostaje dane wejściowe (JSON) i zwraca decyzję.

Reguły pisze się w [Rego](https://www.openpolicyagent.org/docs/policy-language) — deklaratywnym języku wywodzącym się z Datalog, zaprojektowanym do odpytywania złożonych, zagnieżdżonych struktur danych. Prosty przykład bramki w CI, która odrzuca obraz z tagiem `latest`:

```rego
package ci.images

# odrzuć każdy kontener używający :latest
deny contains msg if {
    some c in input.spec.containers
    endswith(c.image, ":latest")
    msg := sprintf("obraz %v używa :latest — przypnij wersję", [c.image])
}
```

```bash
# ta sama reguła jako bramka w pipeline (bez klastra)
$ conftest test deployment.yaml
FAIL - deployment.yaml - ci.images - obraz app:latest używa :latest — przypnij wersję
1 test, 0 passed, 1 failure   # exit 1 → PR nie przechodzi
```

Tu rolę uruchamiacza w CI pełni [Conftest](/katalog/conftest) (Rego poza klastrem), a tę samą politykę w klastrze egzekwuje jako admission webhook [OPA Gatekeeper](/katalog/gatekeeper). Uczciwa uwaga: Rego bywa stromy — opanowanie go to realnie kilkadziesiąt godzin nauki, a w 2026 r. ekosystem OPA przeszedł zmiany właścicielskie (część twórców i inżynierów Styra dołączyła do Apple). To nie podważa dojrzałości projektu, ale warto znać krajobraz alternatyw.

## Nie tylko OPA: krajobraz silników

„Policy-as-code" to kategoria, nie jedno narzędzie. Wybór zależy od tego, *co* egzekwujesz i *kto* ma pisać reguły.

| Silnik | Język / format | Najlepszy do | Cena wyboru |
|---|---|---|---|
| [OPA](/katalog/open-policy-agent) + [Conftest](/katalog/conftest) | Rego | Spójne reguły w całym stacku (K8s, IaC, API, CI) | Stroma krzywa Rego |
| [Kyverno](/katalog/kyverno) | YAML (zasoby K8s) | Governance Kubernetes bez nowego języka | Mocno związany z K8s |
| [Gatekeeper](/katalog/gatekeeper) | Rego (CRD) | Admission control w klastrze na bazie OPA | Tylko klaster |
| Cedar | [Cedar](https://www.cedarpolicy.com/) | Autoryzacja aplikacyjna (czytelna, szybka, analizowalna) | Węższy zakres, ekosystem AWS |
| [Checkov](/katalog/checkov) / [Terrascan](/katalog/terrascan) | wbudowane reguły | Skan IaC out-of-the-box | Mniej elastyczne niż własne reguły |
| [Casbin](/katalog/casbin) | modele (ACL/RBAC/ABAC) | Autoryzacja wewnątrz aplikacji | To biblioteka, nie bramka CI |

Dwie osie pomagają wybrać. Pierwsza: **uniwersalność vs prostota** — OPA daje jeden język na wszystko kosztem nauki Rego; Kyverno zostaje w YAML, ale tylko dla Kubernetes. Druga: **kto czyta regułę** — Cedar jest celowo czytelny i ściśle typowany (łatwiejszy do przejrzenia także dla nie-programisty oraz do automatycznej analizy), Rego bywa gęsty. W EIAC nie stawiamy na konkretne narzędzie, lecz na zasadę: reguła jest kodem, bramką i śladem — niezależnie od silnika.

## Warstwowa płaszczyzna kontroli

Najczęstszy błąd to potraktowanie PaC jak pojedynczego skanu w CI. Dojrzała platforma rozkłada polityki **warstwowo**, tak by każda bramka działała tam, gdzie ma najwięcej kontekstu i najmniej przeszkadza:

- **Źródło i projekt (IDE, PR)** — linty, szablony, walidacja konwencji; najtańsze i najszybsze sprzężenie zwrotne.
- **Build** — polityki nad Dockerfile i obrazami (brak `latest`, brak roota, dozwolone bazowe obrazy), skan zależności ([Trivy](/katalog/trivy)).
- **Plan / provisioning** — reguły nad planem [IaC](/katalog/checkov) (zanim cokolwiek powstanie: brak otwartych portów, wymagane szyfrowanie, tagi właściciela).
- **Deploy / runtime** — admission controller ([Gatekeeper](/katalog/gatekeeper)/[Kyverno](/katalog/kyverno)) odrzuca niezgodne zasoby przy `kubectl apply`/`helm`.

<figure>
<svg viewBox="0 0 780 200" role="img" aria-label="Warstwowa płaszczyzna kontroli policy-as-code wzdłuż cyklu wytwarzania: IDE/PR, Build, Plan IaC, Admission/runtime — w każdym etapie bramka polityki, im później tym wyższy koszt naprawy.">
  <line x1="24" y1="150" x2="756" y2="150" stroke="var(--color-muted)" stroke-width="1.5"/>
  <g font-family="'Space Grotesk', system-ui, sans-serif" fill="currentColor" font-size="13" text-anchor="middle">
    <text x="100" y="170">IDE / PR</text>
    <text x="300" y="170">Build</text>
    <text x="500" y="170">Plan IaC</text>
    <text x="690" y="170">Admission / runtime</text>
  </g>
  <g fill="none" stroke="currentColor" stroke-width="1.5">
    <rect x="44" y="92" width="112" height="40" rx="6"/>
    <rect x="244" y="92" width="112" height="40" rx="6"/>
    <rect x="444" y="92" width="112" height="40" rx="6"/>
    <rect x="634" y="92" width="112" height="40" rx="6"/>
  </g>
  <g font-family="'Space Mono', monospace" fill="var(--color-rust)" font-size="11" text-anchor="middle">
    <text x="100" y="116">lint / spec</text>
    <text x="300" y="116">obraz / SBOM</text>
    <text x="500" y="116">plan deny</text>
    <text x="690" y="116">webhook</text>
  </g>
  <g fill="var(--color-rust)">
    <circle cx="100" cy="150" r="4"/><circle cx="300" cy="150" r="4"/><circle cx="500" cy="150" r="4"/><circle cx="690" cy="150" r="4"/>
  </g>
  <path d="M44 60 H300" fill="none" stroke="var(--color-muted)" stroke-width="1.5"/>
  <path d="M300 60 l-7 -4 v8 z" fill="var(--color-muted)" transform="rotate(180 300 60)"/>
  <text x="60" y="52" font-family="'Space Grotesk', system-ui, sans-serif" fill="var(--color-muted)" font-size="12">taniej, szybciej naprawić ←</text>
  <text x="540" y="52" font-family="'Space Grotesk', system-ui, sans-serif" fill="var(--color-rust)" font-size="12">→ drożej, później</text>
</svg>
<figcaption>Policy-as-code jako płaszczyzna kontroli: ta sama zasada egzekwowana na kolejnych etapach. Im wcześniej bramka złapie naruszenie, tym taniej je naprawić.</figcaption>
</figure>

Kluczowe jest, by **ta sama intencja** była egzekwowana na wielu warstwach: „brak `latest`" sprawdzasz w CI (szybkie sprzężenie dla dewelopera) *i* w admission (twarda gwarancja, że nic nie obejdzie pipeline'u). Warstwy się nie wykluczają — uzupełniają.

## Guardrails, nie bramkarze

Najważniejsza zmiana myślenia: PaC ma być **guardrailem, nie bramkarzem**. Bramkarz blokuje i zmusza do proszenia o zgodę; guardrail wyznacza bezpieczny tor, po którym jedzie się samoobsługowo. Google Cloud opisuje [cztery mechanizmy kontroli platformy](https://cloud.google.com/blog/products/application-modernization/platform-engineering-control-mechanisms): złote ścieżki (domyślne, wspierane drogi), guardrails (automatyczne granice), siatki bezpieczeństwa (wykrywanie po fakcie) i ręczne punkty kontrolne (gdy naprawdę trzeba człowieka). PaC realizuje przede wszystkim guardrails — i to one skalują się najlepiej, bo „kodują osąd raz i stosują go nieustannie".

Z tego wynika praktyczna reguła doboru: **shift-left to nie tylko „wcześniej", ale „wcześniej i automatycznie"** — walidacja tam, gdzie inżynier już pracuje (IDE, PR, CI, deploy), ze sprzężeniem, które jest *szybkie, konkretne i naprawialne*. Polityka, która zwraca „odmowa" bez wskazania, co poprawić, jest bramkarzem. Polityka, która mówi „użyj `var(--space-2)` zamiast `12px`" albo „przypnij wersję obrazu" — jest guardrailem. Różnica decyduje o tym, czy zespoły platformę pokochają, czy zaczną ją obchodzić.

## Policy-as-code w platformie agentowej

Tu PaC przestaje być wygodą, a staje się warunkiem koniecznym. Gdy część pracy w pętli wykonuje agent AI, a nie człowiek, znika naturalny punkt kontroli, jakim był recenzent przy klawiaturze. Pętla narzędziowa agenta sama z siebie **nie ma punktu decyzyjnego** „czy wolno?" — i to policy-as-code go dostarcza: deklaratywną bramkę, przez którą musi przejść każde działanie, niezależnie od tego, czy zainicjował je człowiek, czy model.

To jest dokładnie rdzeń [deterministycznego szkieletu ADP](/blog/deterministyczny-szkielet-adp): nie ufamy modelowi „że zrobi dobrze", tylko zamykamy go w polityce egzekwowanej maszynowo. Im wyżej w [czterech poziomach autonomii](/blog/cztery-poziomy-agentowego-wytwarzania), tym mocniejsze muszą być te bramki — bo tym mniej człowieka zostaje w pętli. PaC łączy się tu wprost z [Security Plane](/blog/security-plane-sekrety-tozsamosc-policy): tożsamość mówi *kto/co* działa (także tożsamość nie-ludzka agenta), a polityka — *co temu komuś wolno*.

```yaml
# Kyverno: w klastrze nic nie wystartuje jako root — dotyczy tak samo
# wdrożeń człowieka, jak i tych zainicjowanych przez agenta
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata: { name: require-non-root }
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-runAsNonRoot
      match: { any: [{ resources: { kinds: ["Pod"] } }] }
      validate:
        message: "kontener musi działać jako non-root"
        pattern:
          spec:
            securityContext: { runAsNonRoot: true }
```

## Zgodność jako produkt uboczny

Ponieważ każde uruchomienie polityki zostawia ślad — co sprawdzono, z jakim wynikiem — PaC daje *za darmo* to, co regulacje wymagają osobno: dowód. Zamiast ręcznych audytów raz na kwartał masz ciągły, maszynowy zapis zgodności. To wprost odpowiada na wymóg [DORA](/blog/dora-w-praktyce-platformy), by zgodność dało się *wykazać*, oraz na oczekiwania [AI Act](/blog/ai-act-a-agentowy-sdlc) co do śladu i nadzoru. „Compliance by design" nie jest hasłem — to konsekwencja tego, że reguła jest kodem, który się wykonuje i loguje.

Granica uczciwości: PaC pokrywa *techniczną* część zgodności. Procesy organizacyjne — rejestr ryzyka, raportowanie incydentów, role i odpowiedzialności — to wciąż praca ludzi. Platforma jest warunkiem koniecznym zgodności, nie wystarczającym.

## Wybierz ścieżkę

Nie ma jednej słusznej drogi wdrożenia — jest sekwencja, którą warto przejść etapami:

1. **Zacznij od jednej bramki w CI** — np. [Conftest](/katalog/conftest) lub [Checkov](/katalog/checkov) na PR. Niski koszt, szybka wartość, uczy zespół myślenia regułami.
2. **Dołóż admission w klastrze** — [Kyverno](/katalog/kyverno) (gdy zespół woli YAML) lub [Gatekeeper](/katalog/gatekeeper) (gdy już używasz Rego). Domyka lukę „co z tym, co omija CI".
3. **Ujednolić język, jeśli rośnie zakres** — gdy reguły mnożą się w wielu miejscach (K8s, IaC, API), rozważ [OPA](/katalog/open-policy-agent)/Rego jako wspólny silnik; do czystej autoryzacji aplikacyjnej — Cedar lub [Casbin](/katalog/casbin).
4. **Traktuj polityki jak produkt** — wersjonuj, testuj, dawaj czytelne komunikaty naprawcze. Guardrail bez dobrego UX zamienia się w bramkarza, którego zespoły obchodzą.

Reguła kciuka: **najpierw jedna warstwa, potem szerokość, na końcu unifikacja języka.** Budowanie od razu uniwersalnej platformy polityk dla problemu, którego jeszcze nie masz, to ten sam over-engineering, przed którym ostrzegaliśmy przy [samej platformie](/blog/platform-engineering-normalizacja-pracy).

## Podsumowanie

Policy-as-code zamienia zasady bezpieczeństwa i zgodności z dokumentów, które nikt nie egzekwuje, w testowalne bramki, które działają same. Jego dojrzała forma to nie skan w CI, lecz warstwowa płaszczyzna kontroli — od IDE po admission — egzekwowana jako guardrail blisko miejsca pracy inżyniera, a nie jako bramkarz na końcu. W platformie agentowej PaC jest tym punktem decyzyjnym, którego pętla agenta sama nie ma, a przy okazji dostarcza ciągły ślad audytowy spełniający wymogi DORA i AI Act. Wybór silnika należy do Ciebie — OPA, Kyverno, Cedar czy inny — bo w EIAC liczy się zasada, nie narzędzie: reguła jest kodem, bramką i śladem. A od strony praktycznej: zacznij od jednej reguły w CI. Zobaczysz, ile spokoju daje świadomość, że standard egzekwuje się sam, a nie zależy od tego, czy ktoś go akurat pamiętał na review.

---


# Wersjonowanie z automatu: SemVer i Conventional Commits

URL: https://eiac.dev/blog/wersjonowanie-semver-conventional-commits
Filar: SDLC / Policy-as-Code
Data: 2026-02-16
Tagi: semver, conventional-commits, release, automation, semantic-release, gitlab
Skrót: Wersja to interfejs komunikacyjny, nie kosmetyka. Jak SemVer i Conventional Commits zamieniają historię commitów w automatyczne, przewidywalne wydania — i gdzie kończy się sens automatu.

Ile razy bumpnąłeś wersję „na oko", bo trzeba było coś wypuścić, a nikt nie pamiętał, czy ta zmiana to jeszcze `1.4.3`, czy już `2.0.0`? U mnie — za dużo razy, i za każdym numer wersji trochę kłamał. Bo numer wersji to najmniejszy interfejs Twojego oprogramowania. Zanim ktokolwiek zajrzy w changelog, podejmuje decyzję na podstawie trzech liczb: czy to bezpieczne, czy coś się zepsuje, czy warto. Jeśli nadaje je człowiek na oko, interfejs kłamie — a wraz z nim cała automatyzacja, która na nim polega.

Ten artykuł pokazuje, jak zamienić wersjonowanie z rytuału w funkcję: deterministyczną, wyprowadzaną wprost z historii commitów. Po drodze: dogłębna analiza problemu, standard **SemVer**, specyfikacja **Conventional Commits** i narzędzia, które spinają to w pipeline.

<div class="callout">
<strong>Teza</strong>
<p>Wersja nie powinna być decyzją podejmowaną na końcu. Powinna być <em>obliczana</em> z tego, co już zapisałeś w commitach.</p>
</div>

## Problem: dlaczego ręczne wersjonowanie zawodzi

Na pierwszy rzut oka nadanie wersji to trywialna czynność — podbij liczbę, otaguj, opublikuj. W praktyce to miejsce, w którym kumuluje się dług całego procesu wydawniczego. Kilka warstw problemu:

### 1. Wersja zależy od wiedzy, która nie jest zapisana

Żeby poprawnie podbić wersję, trzeba wiedzieć, _co_ zmieniło się od ostatniego wydania i _czy_ któraś zmiana łamie kompatybilność. Ta wiedza zwykle żyje w głowach autorów i rozprasza się z każdym dniem. Po dwóch tygodniach i czterdziestu commitach nikt nie odtworzy z pamięci, czy gdzieś nie zmienił się kontrakt API.

### 2. Człowiek myli „dla mnie" z „dla użytkownika"

Autor zmiany ocenia ją z perspektywy implementacji („mała poprawka"), a nie konsumenta API („zmieniła się sygnatura, to breaking change"). To systematyczny błąd poznawczy — i główne źródło wersji, które obiecują kompatybilność, a jej nie dają.

### 3. Changelog rozjeżdża się z kodem

Ręcznie pisany changelog to osobne źródło prawdy, które trzeba pamiętać, by zaktualizować. Im więcej pośpiechu, tym większy dryf między tym, co naprawdę się zmieniło, a tym, co opisano.

### 4. Wydanie staje się wąskim gardłem

Skoro „wydanie" wymaga człowieka, który zbierze odpowiedzialność za numer, changelog i tag — wydania robi się rzadziej, większymi partiami. A większe partie to trudniejszy przegląd, większe ryzyko i wolniejszy feedback. Klasyczna spirala.

### 5. Niespójność między projektami i ludźmi

Każdy nadaje wersje trochę inaczej. W monorepo albo w organizacji z dziesiątkami usług brak jednej, egzekwowalnej reguły oznacza, że „2.3.0" w jednym repo znaczy co innego niż w drugim.

> Wersjonowanie to nie problem „podbicia liczby". To problem **utrwalenia intencji zmiany w momencie jej powstania** i deterministycznego wyprowadzenia z niej konsekwencji.

Rozwiązanie ma więc dwie części: standard, który nadaje liczbom znaczenie (SemVer), oraz konwencję, która utrwala intencję w commicie (Conventional Commits). Reszta to już automat.

## SemVer — kontrakt w trzech liczbach

[Semantic Versioning](https://semver.org) (SemVer 2.0.0) definiuje wersję jako `MAJOR.MINOR.PATCH`, gdzie każdy człon ma ścisłe znaczenie:

| Człon | Kiedy rośnie                     | Obietnica dla konsumenta                      |
| ----- | -------------------------------- | --------------------------------------------- |
| MAJOR | zmiana łamiąca kompatybilność    | „możesz musieć poprawić swój kod"             |
| MINOR | nowa funkcja, wstecznie zgodna   | „możesz aktualizować bezpiecznie, są nowości" |
| PATCH | poprawka błędu, wstecznie zgodna | „aktualizuj bez obaw"                         |

Kluczowa zasada: numer to **kontrakt**, nie metryka aktywności. Podbicie MAJOR nie znaczy „dużo pracy", tylko „złamaliśmy obietnicę zgodności". Podbicie PATCH nie znaczy „mała zmiana", tylko „nic się dla Ciebie nie zmienia poza naprawą".

### Pre-release i metadane builda

SemVer pozwala oznaczyć wersje niestabilne i dołączyć metadane:

```text
1.4.0-rc.1          # pre-release: 1.4.0 jeszcze nie gotowe
1.4.0-beta.2+exp.7  # pre-release + metadane builda (po +)
```

Wersje pre-release mają **niższy priorytet** niż odpowiadające im wydanie (`1.4.0-rc.1 < 1.4.0`). Metadane po `+` są ignorowane przy porównywaniu — służą tylko identyfikacji builda.

### Zakresy: caret i tilde

Menedżery pakietów pozwalają deklarować, na jakie aktualizacje się godzisz. Dwa najważniejsze operatory:

| Zapis    | Znaczenie      | Dopuszcza        |
| -------- | -------------- | ---------------- |
| `^1.4.2` | zgodny z MAJOR | `>=1.4.2 <2.0.0` |
| `~1.4.2` | zgodny z MINOR | `>=1.4.2 <1.5.0` |

`^` (caret) to domyślny wybór w większości ekosystemów — ufasz, że MINOR i PATCH są bezpieczne. To zaufanie działa tylko wtedy, gdy autorzy uczciwie trzymają się SemVer. Stąd waga automatyzacji: jeśli bump liczy maszyna z reguł, kontrakt przestaje zależeć od dyscypliny.

<div class="callout">
<strong>Pułapka 0.x</strong>
<p>Dla wersji <code>0.y.z</code> SemVer <em>nie</em> gwarantuje stabilności — tu nawet MINOR może łamać kompatybilność. „Jedynka" (<code>1.0.0</code>) to deklaracja: „API jest stabilne, od teraz obowiązuje pełny kontrakt".</p>
</div>

## Conventional Commits — commit jako dane

SemVer mówi, _co_ znaczą liczby. Brakuje ogniwa, które w momencie pisania kodu utrwali intencję zmiany w formie nadającej się do maszynowego odczytu. Tym ogniwem jest [Conventional Commits](https://www.conventionalcommits.org) (1.0.0) — lekka konwencja formatu komunikatu commita:

```text
<typ>[opcjonalny zakres][!]: <opis>

[opcjonalne ciało]

[opcjonalne stopki]
```

Przykłady:

```text
feat(catalog): dodaj filtr po filarze
fix(nav): popraw kontrast linku w trybie ciemnym
docs: uzupełnij sekcję deploymentu
refactor(api)!: zmień kształt odpowiedzi /tools
```

Najważniejsze elementy:

- **typ** — `feat`, `fix`, `docs`, `refactor`, `perf`, `test`, `build`, `ci`, `chore` i inne. Tylko dwa mają wpływ na wersję (patrz niżej).
- **zakres** (scope) — opcjonalny obszar zmiany w nawiasie, np. `(catalog)`.
- **`!`** — wykrzyknik przed dwukropkiem oznacza **breaking change**.
- **stopka `BREAKING CHANGE:`** — alternatywny, jawny sposób oznaczenia złamania kompatybilności, z opisem migracji.

```text
feat(api): obsługa paginacji w katalogu

BREAKING CHANGE: endpoint /tools zwraca teraz obiekt { items, next }
zamiast tablicy. Zaktualizuj klientów odczytujących odpowiedź.
```

Zysk jest podwójny: commit staje się **czytelny dla człowieka** (od razu wiadomo, co i gdzie) i **parsowalny dla maszyny** (typ + flaga breaking → konkretny bump SemVer).

## Od commita do wersji: jak liczy się bump

Mapowanie jest proste i deterministyczne. Narzędzie patrzy na wszystkie commity od ostatniego tagu i wybiera **najwyższy** wymagany bump:

| W commitach pojawia się…       | Bump         | Przykład        |
| ------------------------------ | ------------ | --------------- |
| `BREAKING CHANGE` lub `typ!`   | MAJOR        | `1.4.2 → 2.0.0` |
| przynajmniej jeden `feat`      | MINOR        | `1.4.2 → 1.5.0` |
| tylko `fix` (i neutralne typy) | PATCH        | `1.4.2 → 1.4.3` |
| tylko `docs`/`chore`/`test`…   | brak wydania | —               |

Changelog powstaje przy okazji: narzędzie grupuje commity wg typu („Features", „Bug Fixes", „BREAKING CHANGES") i zapisuje je w `CHANGELOG.md`. Jedno źródło prawdy — historia Git — zasila i numer, i notatki, i tag.

## Narzędzia: od konwencji do wydania

Ekosystem dzieli się na trzy role: **egzekwowanie** konwencji przy commicie, **liczenie** wersji i changelogu, oraz **uruchamianie** tego wszystkiego w pipeline.

### Liczenie wersji i wydania

To serce automatyzacji — i tu kończy się różnica „narzędziowa", a zaczyna wybór **modelu wydań**. Dwa dominujące podejścia realizują tę samą ideę (wersja liczona z commitów), różniąc się momentem publikacji:

**Model „release PR".** [release-please](/katalog/release-please) zbiera commity, wylicza wersję i otwiera pull request z podbiciem wersji oraz changelogiem. Publikacja następuje dopiero po scaleniu tego PR — masz więc jawny, recenzowalny artefakt, zanim cokolwiek wyjdzie na świat. To „bramka wersji" wbudowana w proces.

**Model „publish-on-merge".** [semantic-release](/katalog/semantic-release) idzie krok dalej: po merge do gałęzi wydawniczej sam analizuje commity, ustala wersję, generuje changelog i — przez bogaty system wtyczek — publikuje artefakt (npm, GitLab/GitHub Releases, obraz [OCI](https://opencontainers.org/) itd.) oraz odkłada tag. Brak ręcznego kroku to najkrótsza droga od merge do wydania; kontrolę przenosisz wtedy na etap PR z kodem (bo to on jest ostatnią bramką przed `main`).

semantic-release wyróżnia się dodatkowo **kanałami wydawniczymi**: z `main` publikujesz wydania stabilne, z `next`/`beta`/`alpha` — pre-release (`1.5.0-beta.1`), a z gałęzi `1.x` — wydania utrzymaniowe. To kompletny, deklaratywny model cyklu życia wersji.

Ten sam wzorzec mają inne narzędzia: `changesets` (świetny do monorepo — intencję zapisuje się w osobnych plikach, nie tylko w commitach) czy `git-cliff` (sam generator changelogu). Różnią się ergonomią, nie ideą.

### release-please kontra semantic-release

Oba liczą wersję z Conventional Commits, ale realizują dwie różne filozofie wydań. Najważniejsza różnica to **rozdzielenie „przygotowania" od „publikacji"**: release-please je rozdziela (najpierw PR z wersją, publikacja dopiero po jego scaleniu), a semantic-release scala w jeden, automatyczny krok po merge.

| Wymiar                   | release-please                                           | semantic-release                                          |
| ------------------------ | -------------------------------------------------------- | --------------------------------------------------------- |
| Model                    | release PR → publikacja po scaleniu                      | publish-on-merge (od razu po merge)                       |
| Bramka wersji            | wbudowana — osobny PR z wersją i changelogiem            | brak osobnej; bramką jest PR z kodem                      |
| Kontrola momentu wydania | wysoka (mergujesz, gdy chcesz wydać)                     | niska (wydanie = skutek merge’a)                          |
| Publikacja artefaktów    | nie publikuje sama (robi tag/release; publish dokładasz) | publikuje przez wtyczki (npm, Releases, registry…)        |
| Changelog                | `CHANGELOG.md` widoczny w release PR                     | generowany przy wydaniu (wtyczka)                         |
| Pre-release / kanały     | podstawowe                                               | rozbudowane (`next`/`beta`/`alpha`, gałęzie utrzymaniowe) |
| Monorepo                 | natywne (wiele pakietów, osobne release PR-y)            | słabiej, wymaga dodatków                                  |
| Konfiguracja             | manifest + plik konfiguracyjny                           | `.releaserc` + dobór wtyczek                              |
| Krzywa wejścia           | niska                                                    | średnia (wtyczki, tokeny, uprawnienia)                    |

Co z tego wynika w praktyce:

- **Kontrola czasu i treści wydania.** release-please daje „poczekalnię": kilka feature’ów może czekać w jednym release PR, a Ty decydujesz, kiedy je wydać i możesz jeszcze dopieścić notatki. semantic-release wydaje, gdy tylko zmiana wejdzie na gałąź — świetne do ciągłego dostarczania, mniej wygodne, gdy chcesz „zebrać" wydanie albo zsynchronizować je z czymś poza repo.
- **Co znaczy „wydanie".** release-please domyślnie kończy na tagu i wpisie release — samą publikację artefaktu (npm, obraz) dokładasz osobnym krokiem. semantic-release traktuje publikację jako część procesu: jego siłą jest ekosystem wtyczek, który w jednym przebiegu zaktualizuje changelog, opublikuje pakiet, utworzy release i odłoży tag (atomowo — albo wszystko, albo nic).
- **Audyt i zgodność.** Jawny release PR to naturalny punkt przeglądu i zatwierdzenia („czy na pewno 2.0.0?”) — bywa wymagany przy regulacjach. W modelu publish-on-merge ten przegląd musi wydarzyć się wcześniej, na PR z kodem, bo po merge nie ma już ręcznego hamulca.
- **Pre-release i utrzymanie wielu linii.** Jeśli prowadzisz równolegle `1.x`, `2.x` i kanał beta, rozbudowany model gałęzi semantic-release jest tu znacząco wygodniejszy.
- **Monorepo.** Przy wielu pakietach w jednym repo release-please ma przewagę (osobne wersje i release PR-y per pakiet); semantic-release wymaga obejść, a często lepszym wyborem bywa wtedy `changesets`.

W skrócie: wybierz **release-please**, gdy cenisz jawną bramkę wersji, kontrolę momentu wydania i monorepo; wybierz **semantic-release**, gdy chcesz maksymalnej automatyzacji „od merge do opublikowanego artefaktu" i bogatych kanałów wydawniczych.

### Egzekwowanie konwencji

Automatyczne liczenie wersji działa tylko wtedy, gdy commity faktycznie trzymają się konwencji. Dlatego warto ją wymusić: lokalnie (hook pre-commit / `commitlint`) i w CI. Wygodnie zrobić to przez [MegaLinter](/katalog/megalinter), który potrafi uruchomić walidację komunikatów commitów obok reszty linterów — jednym krokiem w pipeline.

### Uruchamianie w pipeline

Cała mechanika żyje w repozytorium i CI — i jest przenośna między platformami. Na [Gitea](/katalog/gitea) odpalisz ją jako Gitea Actions, na [GitLab](/katalog/gitlab) jako pipeline w `.gitlab-ci.yml`, a ten sam automat zadziała też na innym CI. Do przenośnych, kontenerowych kroków pasuje [Dagger](/katalog/dagger), a jeśli wolisz dedykowany silnik — [Woodpecker](/katalog/woodpecker). Dla bezpieczeństwa łańcucha dostaw warto podpisywać tagi/commity wydań, np. bezkluczowo przez [gitsign](/katalog/gitsign).

## Pipeline w praktyce

Ten sam wzorzec, dwie platformy i dwa modele wydań.

**Gitea Actions + release-please (model „release PR").** Przy pushu do `main` powstaje lub aktualizuje się release PR; po jego scaleniu — tag i wydanie.

```yaml
# .gitea/workflows/release.yml
name: release
on:
  push:
    branches: [main]
jobs:
  release-please:
    runs-on: ubuntu-latest
    steps:
      - uses: googleapis/release-please-action@v4
        with:
          release-type: node # albo: simple, python, go…
```

**GitLab CI + semantic-release (model „publish-on-merge").** Po merge do `main` job sam liczy wersję, tworzy changelog, tag i release.

```yaml
# .gitlab-ci.yml
release:
  image: node:20
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
  script:
    - npx semantic-release
```

```json
// .releaserc.json
{
  "branches": ["main", { "name": "beta", "prerelease": true }],
  "plugins": [
    "@semantic-release/commit-analyzer",
    "@semantic-release/release-notes-generator",
    "@semantic-release/changelog",
    "@semantic-release/gitlab",
    "@semantic-release/git"
  ]
}
```

Oba modele sprowadzają się do tego samego cyklu:

<figure>
<svg viewBox="0 0 720 132" role="img" aria-label="Cykl wydania: z commitów automat liczy wersję i changelog, po bramce powstaje tag i release">
  <g fill="none" stroke="currentColor" stroke-width="1.5">
    <rect x="16" y="46" width="150" height="40" rx="20"/>
    <rect x="220" y="42" width="200" height="48" rx="6"/>
    <rect x="556" y="42" width="148" height="48" rx="6" stroke="var(--color-rust)"/>
  </g>
  <g stroke="currentColor" stroke-width="1.5">
    <line x1="166" y1="66" x2="214" y2="66"/>
    <line x1="420" y1="66" x2="550" y2="66"/>
  </g>
  <g fill="currentColor">
    <path d="M214 62 L220 66 L214 70 Z"/>
    <path d="M550 62 L556 66 L550 70 Z"/>
  </g>
  <g font-family="'Space Mono', monospace" font-size="12" fill="currentColor" text-anchor="middle">
    <text x="91" y="70">feat · fix · feat!</text>
  </g>
  <g font-family="'Space Grotesk', system-ui, sans-serif" font-size="12.5" fill="currentColor" text-anchor="middle">
    <text x="320" y="62">automat: liczy wersję</text>
    <text x="320" y="78">i changelog</text>
    <text x="630" y="70" fill="var(--color-rust)">tag vX.Y.Z + release</text>
  </g>
  <g font-family="'Space Mono', monospace" font-size="10" fill="var(--color-muted)" text-anchor="middle">
    <text x="485" y="56">release PR → review</text>
    <text x="485" y="88">albo: merge → publish</text>
  </g>
</svg>
<figcaption>Ten sam cykl w obu modelach: z commitów automat liczy wersję i changelog, a po bramce (release PR albo merge) powstaje tag i wydanie.</figcaption>
</figure>

Walidację konwencji dokładasz jako wcześniejszą bramkę (commitlint / [MegaLinter](/katalog/megalinter)), a podpisywanie tagów jako krok po wydaniu. Każdy element jest deklaratywny i wersjonowany — wydania przestają być czynnością, a stają się właściwością repozytorium.

## Pułapki i dobre praktyki

- **Squash vs merge.** Jeśli scalasz PR-y przez squash, to _tytuł_ squasha musi być zgodny z Conventional Commits — bo to on trafia do historii `main`. Wymuś walidację tytułu PR.
- **`0.x` to nie wymówka.** Brak stabilności w `0.y.z` nie znaczy, że można ignorować breaking changes — oznaczaj je, by changelog był uczciwy, i świadomie zaplanuj `1.0.0`.
- **Nie kłam typem.** `feat` użyty do poprawki zawyża wersje i psuje zaufanie do `^`. Konsekwencja w typach jest ważniejsza niż ich liczba.
- **Monorepo.** Przy wielu pakietach w jednym repo rozważ narzędzie świadome granic pakietów (np. changesets) albo release-please w trybie wielopakietowym — inaczej jeden `feat` podbije wszystko.
- **Człowiek w pętli.** Automat ma _przygotować_ wydanie (PR/draft), nie publikować bez kontroli. To ta sama zasada, co przy każdym automacie treści i infrastruktury — zgodna z podejściem [Policy-as-Code](/blog/policy-as-code-dla-zespolow): reguły egzekwuje maszyna, decyzję zatwierdza człowiek.

## Podsumowanie

Ręczne wersjonowanie zawodzi, bo wymaga, by człowiek odtworzył i poprawnie ocenił wiedzę, której nigdzie nie zapisał. SemVer nadaje trzem liczbom znaczenie kontraktu; Conventional Commits utrwalają intencję zmiany w chwili jej powstania; automat — czy to [release-please](/katalog/release-please) (model „release PR"), czy [semantic-release](/katalog/semantic-release) (model „publish-on-merge") — zamienia tę historię w deterministyczny numer, changelog i tag. Platforma, na której to działa ([Gitea](/katalog/gitea), [GitLab](/katalog/gitlab) czy inna), jest tu wymienna.

Najważniejsze nie jest jednak narzędzie, lecz podejście: wersja przestaje być decyzją podejmowaną w pośpiechu na końcu, a staje się obliczalną konsekwencją tego, jak pracujesz. Czyli dokładnie tym, czym numer wersji być powinien. Weź to na warsztat na jednym repo — raz skonfigurowany automat sprawia, że o wersjonowaniu po prostu przestajesz myśleć. A to jedna z przyjemniejszych rzeczy, jakie możesz sobie sprawić. :)

---

======== KATALOG ========


## age — Security-as-Code

URL: https://eiac.dev/katalog/age
Repo: https://github.com/FiloSottile/age
Licencja: BSD-3-Clause

age to proste i nowoczesne narzędzie (oraz biblioteka Go) do szyfrowania plików. Stawia na minimalizm: małe, jawne klucze, brak opcji konfiguracyjnych i kompozycyjność w stylu UNIX. Świetnie nadaje się do szyfrowania sekretów, backupów czy artefaktów — i jest domyślnym, wygodnym backendem kluczy dla [SOPS](/katalog/sops).

## Kiedy używać

- Potrzebujesz prostego szyfrowania plików bez ciężaru PGP.
- Szyfrujesz sekrety/backupy w skryptach i CI.
- Chcesz kluczy łatwych do zarządzania i wersjonowania.

## Przykład użycia

```bash
age-keygen -o key.txt                      # klucz prywatny + publiczny
age -r age1qz... -o secret.age secret.txt  # szyfrowanie do odbiorcy
age -d -i key.txt secret.age               # odszyfrowanie
```

## Warto wiedzieć

- Idealny jako backend kluczy dla [SOPS](/katalog/sops).
- Małe klucze łatwo trzymać w sekretach CI/menedżerze sekretów.

---


## Ansible — Infrastructure-as-Code

URL: https://eiac.dev/katalog/ansible
Repo: https://github.com/ansible/ansible
Licencja: GPL-3.0

Ansible automatyzuje konfigurację serwerów, wdrożenia aplikacji i zadania operacyjne, używając prostych plików YAML (playbooków). Działa bezagentowo — łączy się przez SSH (lub WinRM), więc nie wymaga instalowania niczego na hostach docelowych. Moduły są idempotentne: ponowne uruchomienie playbooka nie zmienia już zgodnego stanu.

## Kiedy używać

- Konfigurujesz istniejące serwery (pakiety, usługi, pliki) w powtarzalny sposób.
- Orkiestrujesz wieloetapowe wdrożenia i zadania utrzymaniowe.
- Wolisz podejście proceduralne/idempotentne bez instalowania agentów.

## Przykład użycia

```yaml
- hosts: web
  become: true
  tasks:
    - name: Zainstaluj nginx
      ansible.builtin.package:
        name: nginx
        state: present
    - name: Uruchom i włącz usługę
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true
```

```bash
ansible-playbook -i inventory.ini site.yml
```

## Warto wiedzieć

- Świetny do konfiguracji i orkiestracji; do provisioningu chmury często łączony z [Terraform](/katalog/terraform).
- Role i kolekcje (Ansible Galaxy) pozwalają reużywać gotowe komponenty.

---


## APM (Agent Package Manager) — SDLC / Policy-as-Code

URL: https://eiac.dev/katalog/apm
Repo: https://github.com/microsoft/apm
Licencja: MIT

APM (Agent Package Manager) traktuje **kontekst agenta jak zależności kodu** — tak jak npm czy pip traktują biblioteki. W jednym pliku `apm.yml` deklarujesz skille, prompty, instrukcje, wtyczki i serwery MCP, których potrzebuje projekt, a każdy, kto sklonuje repo, po `apm install` dostaje identyczną konfigurację agenta — na GitHub Copilot, Claude Code, Cursor, OpenCode, Codex, Gemini i Windsurf. Lockfile przypina wersje i hasze treści, więc świeży klon odtwarza setup co do bajta.

## Kiedy używać

- Chcesz **odtwarzalnego, przenośnego kontekstu agenta** wersjonowanego razem z kodem (agent-context-as-code).
- Ujednolicasz pracę wielu „harnessów" AI w zespole — jeden manifest, każde narzędzie skonfigurowane tak samo.
- Potrzebujesz governance nad tym, co agent może zainstalować (skille, MCP) — na poziomie repo, org i przedsiębiorstwa.

## Przykład użycia

```yaml
# apm.yml — jedzie z repo, jak package.json
name: my-project
version: 1.0.0
dependencies:
  apm:
    - anthropics/skills/skills/frontend-design
    - github/awesome-copilot/plugins/context-engineering#v2.1
  mcp:
    - io.github.github/github-mcp-server
```

```bash
git clone <repo> && cd <repo> && apm install
```

## Warto wiedzieć

- Zbudowany na otwartych standardach: [AGENTS.md](https://agents.md), [Agent Skills](https://agentskills.io) i [MCP](https://modelcontextprotocol.io); bez centralnego rejestru — zależności to adresy repozytoriów Git (mniejsza powierzchnia ataku).
- Secure-by-default: skan ukrytego Unicode, przypięte hasze integralności, blokada tranzytywnych serwerów MCP; polityki (`apm-policy.yml`) egzekwowane przy instalacji — to [policy-as-code](/blog/policy-as-code-dla-zespolow) dla kontekstu agenta.
- Naturalny element [deterministycznego szkieletu ADP](/blog/deterministyczny-szkielet-adp): odtwarzalny, audytowalny wsad dla agentów w [czterech poziomach autonomii](/blog/cztery-poziomy-agentowego-wytwarzania).

---


## Argo CD — SDLC / Policy-as-Code

URL: https://eiac.dev/katalog/argo-cd
Repo: https://github.com/argoproj/argo-cd
Licencja: Apache-2.0

Argo CD to deklaratywne narzędzie continuous delivery dla Kubernetes w modelu GitOps. Repozytorium Git jest źródłem prawdy o pożądanym stanie klastra; Argo CD nieustannie porównuje ten stan z rzeczywistym i synchronizuje różnice (automatycznie lub po akceptacji). Dostajesz pełną historię zmian, łatwe wycofywanie i czytelny podgląd „drift" między Gitem a klastrem.

## Kiedy używać

- Wdrażasz na Kubernetes i chcesz, by każda zmiana szła przez Git (audyt, review, rollback).
- Zarządzasz wieloma klastrami/środowiskami z jednego miejsca.
- Łączysz z [Helm](/katalog/helm) lub Kustomize do szablonowania manifestów.

## Przykład użycia

```yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: eiac-web
spec:
  project: default
  source:
    repoURL: https://git.eiac.dev/eiac/deploy.git
    path: web
    targetRevision: main
  destination:
    server: https://kubernetes.default.svc
    namespace: web
  syncPolicy:
    automated: { prune: true, selfHeal: true }
```

`selfHeal` przywróci stan z Gita, jeśli ktoś zmieni zasób ręcznie w klastrze.

## Warto wiedzieć

- Repo z manifestami trzymamy na Gitei — Argo CD ciągnie z dowolnego Git.
- `prune` usuwa zasoby skasowane w repo; włączaj świadomie.

---


## Argo CD Vault Plugin — Security-as-Code

URL: https://eiac.dev/katalog/argocd-vault-plugin
Repo: https://github.com/argoproj-labs/argocd-vault-plugin
Licencja: Apache-2.0

Argo CD Vault Plugin rozwiązuje problem sekretów w GitOps: w repo trzymasz manifesty z placeholderami zamiast wartości, a wtyczka podczas synchronizacji pobiera prawdziwe sekrety z backendu ([Vault](/katalog/vault), [OpenBao](/katalog/openbao), menedżery chmurowe) i wstrzykuje je do zasobów Kubernetes. Dzięki temu sekrety nigdy nie lądują w Git, a deklaratywny model [Argo CD](/katalog/argo-cd) pozostaje nienaruszony.

## Kiedy używać

- Robisz GitOps z [Argo CD](/katalog/argo-cd) i potrzebujesz sekretów bez trzymania ich w repo.
- Masz już backend sekretów (Vault/OpenBao/chmura) jako źródło prawdy.
- Chcesz placeholdery w manifestach zamiast zaszyfrowanych wartości.

## Przykład użycia

```yaml
# manifest w repo — placeholder zamiast wartości
apiVersion: v1
kind: Secret
metadata: { name: db }
stringData:
  password: <path:secret/data/eiac/db#password>
```

Przy synchronizacji wtyczka podstawia wartość z Vaulta.

## Warto wiedzieć

- Alternatywa wobec szyfrowania w repo ([SOPS](/katalog/sops)) — tu sekrety zostają w backendzie.
- Wymaga skonfigurowanego dostępu Argo CD do backendu sekretów.

---


## Backstage — SDLC / Policy-as-Code

URL: https://eiac.dev/katalog/backstage
Repo: https://github.com/backstage/backstage
Licencja: Apache-2.0

Backstage to framework do budowy wewnętrznych portali developerskich (IDP). Skupia w jednym miejscu katalog serwisów, dokumentację (TechDocs), szablony scaffoldingu i wtyczki do narzędzi. Kluczowe: encje opisujesz jako pliki `catalog-info.yaml` w repozytoriach, więc katalog organizacji jest „as-code" — wersjonowany i utrzymywany razem z kodem usług.

## Kiedy używać

- Masz wiele serwisów/zespołów i chcesz jednego źródła wiedzy o nich.
- Standaryzujesz zakładanie nowych projektów (Software Templates).
- Chcesz, by katalog i dokumentacja żyły w repo, nie w wiki.

## Przykład użycia

```yaml
# catalog-info.yaml w repo usługi
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: eiac-web
  annotations:
    backstage.io/techdocs-ref: dir:.
spec:
  type: website
  lifecycle: production
  owner: team-platform
```

Backstage zaciąga ten plik i pokazuje usługę w katalogu wraz z dokumentacją.

## Warto wiedzieć

- Wymaga utrzymania (to aplikacja, nie SaaS), ale daje pełną kontrolę.
- Bogaty ekosystem wtyczek; integruje CI/CD, chmurę i obserwowalność.

---


## Buildah — App-as-Code

URL: https://eiac.dev/katalog/buildah
Repo: https://github.com/containers/buildah
Licencja: Apache-2.0

Buildah buduje obrazy zgodne z OCI bez działającego demona Dockera — z Dockerfile albo skryptem krok po kroku. Działa rootless, dobrze nadaje się do CI i pozwala precyzyjnie kontrolować zawartość warstw. Budowanie obrazów staje się powtarzalnym, skryptowalnym krokiem pipeline'u, bez zależności od demona w tle.

## Kiedy używać

- Budujesz obrazy w CI bez demona Dockera (bezpieczniej, rootless).
- Chcesz pełnej kontroli nad warstwami (skryptowe budowanie).
- Standaryzujesz produkcję obrazów OCI.

## Przykład użycia

```bash
buildah bud -t registry.eiac.dev/eiac/web:1.0.0 .   # z Dockerfile
# albo krok po kroku:
ctr=$(buildah from node:20)
buildah run $ctr -- npm ci
buildah commit $ctr eiac/web
```

## Warto wiedzieć

- Z rodziny Podman; dobrze współgra ze skanami [Trivy](/katalog/trivy)/[Grype](/katalog/grype).
- Obrazy publikujesz do rejestru jak [Harbor](/katalog/harbor).

---


## Casbin — Security-as-Code

URL: https://eiac.dev/katalog/casbin
Repo: https://github.com/casbin/casbin
Licencja: Apache-2.0

Casbin to biblioteka autoryzacji, w której logikę dostępu opisujesz deklaratywnie: model (np. RBAC, ABAC, ACL) i polityki trzymasz w plikach lub bazie, a kod tylko pyta „czy ten podmiot może wykonać tę akcję na tym zasobie?". Dzięki temu reguły dostępu są oddzielone od aplikacji, wersjonowane i spójne między usługami — dostępny jest w wielu językach (Go, Node, Python, PHP i inne).

## Kiedy używać

- Potrzebujesz elastycznej autoryzacji (role, atrybuty) wspólnej dla wielu usług.
- Chcesz oddzielić reguły dostępu od kodu aplikacji.
- Zależy Ci na jednym modelu autoryzacji w różnych językach.

## Przykład użycia

```ini
# model.conf — definicja RBAC
[request_definition]
r = sub, obj, act
[policy_definition]
p = sub, obj, act
[role_definition]
g = _, _
[matchers]
m = g(r.sub, p.sub) && r.obj == p.obj && r.act == p.act
```

```csv
# policy.csv
p, editor, article, write
g, alice, editor
```

## Warto wiedzieć

- Działa na poziomie aplikacji (authz), podczas gdy [Open Policy Agent](/katalog/open-policy-agent) jest uniwersalnym silnikiem polityk.
- Polityki możesz trzymać w Gicie albo w bazie (adaptery).

---


## cert-manager — Security-as-Code

URL: https://eiac.dev/katalog/cert-manager
Repo: https://github.com/cert-manager/cert-manager
Licencja: Apache-2.0

cert-manager automatyzuje wydawanie i odnawianie certyfikatów TLS w Kubernetes. Certyfikaty i ich źródła (Let's Encrypt/ACME, własne CA, [Vault](/katalog/vault)) opisujesz jako obiekty Kubernetes (CRD), a kontroler dba o ich pozyskanie, montowanie w sekretach i odnawianie przed wygaśnięciem. TLS staje się deklaratywnym, samonaprawiającym się elementem klastra.

## Kiedy używać

- Chcesz automatycznego, odnawialnego TLS dla usług w [Kubernetes](/katalog/kubernetes).
- Wydajesz certyfikaty z ACME (wildcard przez DNS-01) lub własnego CA.
- Zależy Ci na certyfikatach „as-code" zamiast ręcznego zarządzania.

## Przykład użycia

```yaml
apiVersion: cert-manager.io/v1
kind: Certificate
metadata: { name: eiac-tls, namespace: web }
spec:
  secretName: eiac-tls
  dnsNames: ["eiac.dev", "www.eiac.dev"]
  issuerRef: { name: letsencrypt, kind: ClusterIssuer }
```

## Warto wiedzieć

- Poza klastrem podobną rolę pełni [lego](/katalog/lego) (ACME CLI/biblioteka).
- Integruje DNS-01 z dziesiątkami dostawców DNS (też przez [external-dns](/katalog/external-dns)).

---


## Checkov — Security-as-Code

URL: https://eiac.dev/katalog/checkov
Repo: https://github.com/bridgecrewio/checkov
Licencja: Apache-2.0

Checkov analizuje statycznie infrastrukturę jako kod (Terraform, CloudFormation, Kubernetes, Helm, Dockerfile, ARM) i wykrywa błędy konfiguracji oraz naruszenia zasad bezpieczeństwa, zanim trafią na produkcję. Ma setki wbudowanych reguł, a własne polityki zapiszesz w Pythonie lub YAML — bezpieczeństwo staje się bramką w pipeline, nie ręcznym przeglądem.

## Kiedy używać

- Skanujesz [Terraform](/katalog/terraform)/[Kubernetes](/katalog/kubernetes) pod kątem złych konfiguracji w CI.
- Chcesz egzekwować własne reguły zgodności (custom policies).
- Zależy Ci na szybkim feedbacku już na etapie PR.

## Przykład użycia

```bash
checkov -d .                       # skan katalogu IaC
checkov -d . --compact --quiet     # tylko naruszenia
```

```yaml
# krok w Gitea Actions — twarda bramka
- run: checkov -d infra --soft-fail-on LOW
```

## Warto wiedzieć

- Uzupełnia skan obrazów/zależności ([Trivy](/katalog/trivy)) o warstwę polityk IaC.
- Alternatywy o podobnym zakresie: Terrascan, KICS.

---


## ClusterFuzzLite — Security-as-Code

URL: https://eiac.dev/katalog/clusterfuzzlite
Repo: https://github.com/google/clusterfuzzlite
Licencja: Apache-2.0

ClusterFuzzLite to lekka wersja ClusterFuzz przeznaczona do uruchamiania fuzzingu bezpośrednio w CI. Przy każdym pull requeście testuje zmieniony kod losowymi/wygenerowanymi danymi wejściowymi, wyłapując crash-e i błędy bezpieczeństwa zanim trafią na produkcję. Konfigurację trzymasz w repo, więc fuzzing staje się powtarzalnym krokiem pipeline'u, a nie jednorazową akcją.

## Kiedy używać

- Chcesz wykrywać błędy pamięci/parsowania i podatności wcześnie, w PR.
- Masz kod podatny na nietypowe dane wejściowe (parsery, formaty, protokoły).
- Wolisz fuzzing zintegrowany z CI niż osobną infrastrukturę.

## Przykład użycia

```yaml
# krok w CI (skrót) — fuzzing przy PR
- run: |
    python infra/cifuzz/cifuzz.py \
      --fuzz-seconds 300 --sanitizer address
```

Wykryte awarie raportowane są wraz z reprodukującym wejściem.

## Warto wiedzieć

- Uzupełnia skany statyczne ([Trivy](/katalog/trivy)/[Checkov](/katalog/checkov)) o testy dynamiczne.
- Najwięcej daje przy kodzie przetwarzającym nieufne dane wejściowe.

---


## Coder — App-as-Code

URL: https://eiac.dev/katalog/coder
Repo: https://github.com/coder/coder
Licencja: AGPL-3.0

Coder to samodzielnie hostowana platforma do tworzenia zdalnych środowisk deweloperskich (CDE). Szablony workspace'ów definiujesz w… [Terraform](/katalog/terraform) — więc całe środowisko (maszyna, kontener, narzędzia, dostęp) jest kodem, wersjonowanym i powtarzalnym. Deweloperzy dostają spójne, gotowe środowiska na żądanie, a Ty kontrolujesz zasoby i bezpieczeństwo.

## Kiedy używać

- Chcesz spójnych, odtwarzalnych środowisk dev dla zespołu (i agentów AI).
- Standaryzujesz onboarding i eliminujesz „u mnie działa".
- Wolisz self-hosting i kontrolę nad zasobami/dostępem.

## Przykład użycia

```hcl
# szablon workspace (Terraform)
resource "docker_container" "workspace" {
  image = "codercom/enterprise-base:ubuntu"
  name  = "eiac-${data.coder_workspace.me.name}"
}
```

```bash
coder templates push eiac
coder create --template eiac my-dev
```

## Warto wiedzieć

- Szablony to Terraform → środowiska prowizjonujesz jak infrastrukturę.
- Dobrze pasuje do pracy z agentami AI w izolowanych, kontrolowanych workspace'ach.

---


## Conftest — SDLC / Policy-as-Code

URL: https://eiac.dev/katalog/conftest
Repo: https://github.com/open-policy-agent/conftest
Licencja: Apache-2.0

Conftest pozwala pisać testy względem ustrukturyzowanych plików konfiguracyjnych — manifestów Kubernetes, planów Terraform, Dockerfile, YAML/JSON/HCL — przy użyciu języka Rego z [Open Policy Agent](/katalog/open-policy-agent). Reguły trzymasz w repo i uruchamiasz jako krok CI, dzięki czemu zgodność konfiguracji jest deterministyczną bramką, a nie audytem po wdrożeniu.

## Kiedy używać

- Chcesz egzekwować własne reguły na manifestach/IaC w pipeline (np. zakaz `:latest`, wymagane labelki, limity).
- Wolisz Rego i ekosystem OPA, ale potrzebujesz prostego CLI do plików, nie serwera polityk.
- Standaryzujesz bramki konfiguracji w wielu repozytoriach.

## Przykład użycia

```rego
# policy/deployment.rego
package main

deny contains msg if {
  input.kind == "Deployment"
  not input.spec.template.spec.securityContext.runAsNonRoot
  msg := "kontener musi działać jako non-root"
}
```

```bash
conftest test k8s/ --policy policy/      # bramka w CI
```

## Warto wiedzieć

- Ten sam język (Rego) co [OPA](/katalog/open-policy-agent) i egzekwowanie w klastrze przez [OPA Gatekeeper](/katalog/gatekeeper) — statycznie w CI, dynamicznie w klastrze.
- Uzupełnia skanery jak [Checkov](/katalog/checkov)/[Trivy](/katalog/trivy) o Twoje własne, dziedzinowe reguły.

---


## Crossplane — Infrastructure-as-Code

URL: https://eiac.dev/katalog/crossplane
Repo: https://github.com/crossplane/crossplane
Licencja: Apache-2.0

Crossplane zamienia Kubernetes w uniwersalny control plane do zarządzania infrastrukturą. Zasoby chmurowe deklarujesz jako obiekty Kubernetes, a kontrolery nieustannie uzgadniają stan rzeczywisty z pożądanym (reconciliation). Pozwala też budować własne, wysokopoziomowe abstrakcje (Compositions) i udostępniać je zespołom jako self-service.

## Kiedy używać

- Standaryzujesz na Kubernetes i chcesz tym samym API zarządzać też infrastrukturą.
- Budujesz wewnętrzną platformę (IDP) z self-service dla deweloperów.
- Zależy Ci na ciągłym uzgadnianiu stanu, nie jednorazowym `apply`.

## Przykład użycia

```yaml
apiVersion: s3.aws.upbound.io/v1beta1
kind: Bucket
metadata:
  name: eiac-assets
spec:
  forProvider:
    region: eu-central-1
```

```bash
kubectl apply -f bucket.yaml
kubectl get buckets
```

Crossplane utrzyma zasób w zadanym stanie — jeśli ktoś zmieni go ręcznie, kontroler go skoryguje.

## Warto wiedzieć

- Projekt CNCF; dojrzały ekosystem providerów (Upbound).
- Compositions + Claims pozwalają ukryć złożoność za prostym API dla zespołów.

---


## Dagger — SDLC / Policy-as-Code

URL: https://eiac.dev/katalog/dagger
Repo: https://github.com/dagger/dagger
Licencja: Apache-2.0

Dagger pozwala definiować pipeline'y CI/CD jako kod uruchamiany w kontenerach, identycznie lokalnie i na dowolnym CI. Każdy krok to operacja na kontenerach z cache'owaniem, więc buildy są powtarzalne i szybkie, a logikę pipeline'u piszesz w wybranym języku (Go, Python, TypeScript) albo wywołujesz przez CLI. Koniec z „działa tylko na CI" — ten sam pipeline odpalisz na laptopie.

## Kiedy używać

- Chcesz przenośnych pipeline'ów niezwiązanych z jednym dostawcą CI (np. Gitea Actions, ale też lokalnie).
- Zależy Ci na powtarzalności i cache'owaniu kroków build/test.
- Wolisz logikę CI w prawdziwym języku zamiast rozrastającego się YAML-a.

## Przykład użycia

```bash
# ten sam pipeline lokalnie i w CI
dagger call test --source=.
dagger call build --source=. export --path=./dist
```

```go
// funkcja pipeline w Go (skrót)
func (m *Eiac) Test(ctx context.Context, source *Directory) (string, error) {
    return dag.Container().From("node:20").
        WithDirectory("/src", source).WithWorkdir("/src").
        WithExec([]string{"npm", "ci"}).
        WithExec([]string{"npm", "test"}).
        Stdout(ctx)
}
```

## Warto wiedzieć

- Uruchamiasz z dowolnego CI — wystarczy Docker; dobrze pasuje do Gitea Actions.
- Cache warstw kontenerów znacząco skraca czas powtarzanych buildów.

---


## Dex — Security-as-Code

URL: https://eiac.dev/katalog/dex
Repo: https://github.com/dexidp/dex
Licencja: Apache-2.0

Dex to dostawca tożsamości OpenID Connect, który działa jako „pośrednik" do innych źródeł logowania (LDAP, SAML, GitHub, Google i inne) przez pluggable connectors. Aplikacje integrują się z jednym, standardowym OIDC, a Dex federuje uwierzytelnianie do wybranych backendów. Konfigurację (connectory, klienci) trzymasz deklaratywnie — tożsamość staje się częścią infrastruktury jako kod.

## Kiedy używać

- Chcesz jednego punktu OIDC przed wieloma źródłami logowania.
- Dodajesz SSO do Kubernetes, [Argo CD](/katalog/argo-cd), wewnętrznych narzędzi.
- Wolisz lekki IdP konfigurowany deklaratywnie.

## Przykład użycia

```yaml
# config.yaml (fragment)
issuer: https://auth.eiac.dev/dex
connectors:
  - type: github
    id: github
    config: { clientID: $GH_ID, clientSecret: $GH_SECRET }
staticClients:
  - id: argo-cd
    redirectURIs: ["https://cd.eiac.dev/auth/callback"]
    name: Argo CD
```

## Warto wiedzieć

- Lekki broker tożsamości; do pełnego OAuth2/OIDC „as a service" zob. [Ory Hydra](/katalog/ory-hydra).
- Bardzo popularny jako warstwa SSO dla Kubernetes i Argo CD.

---


## Encore — App-as-Code

URL: https://eiac.dev/katalog/encore
Repo: https://github.com/encoredev/encore
Licencja: MPL-2.0

Encore to framework do backendów, w którym infrastrukturę wywodzi się z kodu. Deklarujesz serwisy, endpointy, bazy danych czy kolejki jako konstrukcje w kodzie (Go lub TypeScript), a Encore analizuje je statycznie i sam provisionuje potrzebne zasoby — lokalnie i w chmurze. Stawia na konwencję zamiast konfiguracji, więc mniej „kleju" infrastrukturalnego.

## Kiedy używać

- Budujesz backend/mikroserwisy i chcesz, by infrastruktura wynikała z kodu bez osobnego IaC.
- Cenisz konwencję, wbudowane tracing/obserwowalność i lokalny dashboard.
- Zespół pracuje w Go lub TypeScript.

## Przykład użycia

```ts
import { api } from "encore.dev/api";

export const hello = api(
  { method: "GET", path: "/hello/:name", expose: true },
  async ({ name }: { name: string }) => {
    return { message: `Cześć, ${name}!` };
  }
);
```

```bash
encore run      # lokalnie, z dashboardem
encore deploy   # wdrożenie
```

## Warto wiedzieć

- Mocniejsza konwencja niż [SST](/katalog/sst) — mniej elastyczności, mniej decyzji.
- Można hostować na Encore Cloud lub eksportować do własnej chmury.

---


## env0 — Infrastructure-as-Code

URL: https://eiac.dev/katalog/env0
Licencja: Proprietary

env0 to komercyjna platforma automatyzacji IaC (TACOS), która obok standardowego zestawu (GitOps, RBAC, drift detection, polityki) kładzie wyraźny nacisk na **FinOps** — widoczność i kontrolę kosztów infrastruktury. Obsługuje wiele silników w jednym miejscu: [Terraform](/katalog/terraform), [OpenTofu](/katalog/opentofu), [Terragrunt](/katalog/terragrunt), [Pulumi](/katalog/pulumi), [Helm](/katalog/helm) i [Kubernetes](/katalog/kubernetes).

## Kiedy używać

- Chcesz jedną platformę na wiele narzędzi IaC z kontrolą kosztów (FinOps) w komplecie.
- Potrzebujesz samoobsługowych szablonów środowisk dla zespołów (self-service).
- Zależy Ci na drift detection, RBAC i politykach w jednym przepływie.

## Przykład użycia

```yaml
# env0.yml — definicja środowiska jako szablonu samoobsługowego
deploy:
  steps:
    terraformPlan:
      after: [ "conftest test $TF_PLAN" ]
configuration:
  - name: TF_VAR_region
    value: eu-central-1
```

## Warto wiedzieć

- Rozliczenia per apply / per środowisko; brak wieczystego darmowego planu (tylko trial).
- Alternatywy: [Spacelift](/katalog/spacelift) (mocny GitOps), [Scalr](/katalog/scalr) (drop-in TFC), [OpenTaco](/katalog/digger) (open-source, w Twoim CI).
- Kontrola kosztów łączy się naturalnie z obserwowalnością platformy (FinOps/GreenOps).

---


## ExternalDNS — Infrastructure-as-Code

URL: https://eiac.dev/katalog/external-dns
Repo: https://github.com/kubernetes-sigs/external-dns
Licencja: Apache-2.0

ExternalDNS synchronizuje rekordy DNS u zewnętrznych dostawców (Cloudflare, Route 53, Google i dziesiątki innych) na podstawie zasobów Kubernetes — Service i Ingress. Zamiast ręcznie zakładać wpisy DNS, deklarujesz je adnotacjami/hostami w manifestach, a kontroler utrzymuje strefę w zgodzie z klastrem. DNS staje się kodem, wersjonowanym razem z aplikacją.

## Kiedy używać

- Chcesz, by wpisy DNS powstawały automatycznie z Ingress/Service.
- Zarządzasz wieloma domenami/strefami i nie chcesz robić tego ręcznie.
- Pracujesz w GitOps i traktujesz DNS jak resztę infrastruktury.

## Przykład użycia

```yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web
  annotations:
    external-dns.alpha.kubernetes.io/hostname: eiac.dev
spec:
  rules: [{ host: eiac.dev, http: { paths: [ ... ] } }]
```

ExternalDNS utworzy i zaktualizuje rekord `eiac.dev` u dostawcy DNS.

## Warto wiedzieć

- Świetnie współgra z [cert-manager](/katalog/cert-manager) (DNS-01) i [Kubernetes](/katalog/kubernetes).
- Wspiera wielu providerów DNS przez jeden kontroler.

---


## Falco — Security-as-Code

URL: https://eiac.dev/katalog/falco
Repo: https://github.com/falcosecurity/falco
Licencja: Apache-2.0

Falco to silnik wykrywania zagrożeń w czasie działania. Obserwuje wywołania systemowe jądra (i zdarzenia Kubernetes) i w czasie rzeczywistym alarmuje o podejrzanych zachowaniach — uruchomieniu powłoki w kontenerze, zapisie do wrażliwych ścieżek, nietypowych połączeniach sieciowych. Reguły opisujesz deklaratywnie w YAML, więc polityka detekcji jest wersjonowana i recenzowana jak kod.

## Kiedy używać

- Potrzebujesz wykrywania zagrożeń w runtime, nie tylko skanów statycznych.
- Działasz na Kubernetes/Linux i chcesz alertów o anomaliach zachowania.
- Chcesz reguł detekcji utrzymywanych „as-code".

## Przykład użycia

```yaml
# reguła: powłoka uruchomiona w kontenerze
- rule: Terminal shell in container
  desc: Wykryto powłokę interaktywną w kontenerze
  condition: spawned_process and container and shell_procs
  output: "Powłoka w kontenerze (proc=%proc.name pod=%k8s.pod.name)"
  priority: WARNING
```

```bash
falco -r custom-rules.yaml
```

## Warto wiedzieć

- Projekt CNCF; uzupełnia skany statyczne ([Trivy](/katalog/trivy)) o warstwę runtime.
- Alerty kierujesz do SIEM/alertingu przez Falcosidekick.

---


## Flux — SDLC / Policy-as-Code

URL: https://eiac.dev/katalog/flux
Repo: https://github.com/fluxcd/flux2
Licencja: Apache-2.0

Flux to zestaw kontrolerów GitOps (GitOps Toolkit), które utrzymują stan klastra Kubernetes zgodny z repozytorium Git. Definiujesz źródła (Git, Helm, OCI) i obiekty synchronizacji, a Flux automatycznie pobiera zmiany, stosuje je i pilnuje, by klaster nie „odjechał" od repo. Wszystko jest deklaratywne i wersjonowane — wdrożenia stają się zwykłymi commitami.

## Kiedy używać

- Chcesz GitOps na Kubernetes z natywnymi kontrolerami (CRD).
- Automatyzujesz wdrożenia Helm/Kustomize/OCI z Gita.
- Zależy Ci na auto-synchronizacji i wykrywaniu dryfu.

## Przykład użycia

```yaml
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata: { name: web, namespace: flux-system }
spec:
  interval: 5m
  sourceRef: { kind: GitRepository, name: eiac }
  path: ./deploy/web
  prune: true
```

## Warto wiedzieć

- Alternatywa/uzupełnienie [Argo CD](/katalog/argo-cd) — Flux jest bardziej „kontrolerowy", Argo ma bogaty UI.
- Świetnie łączy się z [Helm](/katalog/helm) i [Kustomize](/katalog/kustomize); repo trzymamy na Gitei.

---


## Gitea — SDLC / Policy-as-Code

URL: https://eiac.dev/katalog/gitea
Repo: https://github.com/go-gitea/gitea
Licencja: MIT

Gitea to lekka, samodzielnie hostowana platforma do wytwarzania oprogramowania: hosting repozytoriów Git, pull requesty i code review, rejestr pakietów oraz wbudowane **Gitea Actions** (CI/CD zgodne składniowo z GitHub Actions). Wszystko działa z jednego, niewymagającego binarium — to pełna kontrola nad kodem i pipeline'ami u siebie. eiac.dev hostuje na niej repo i automaty.

## Kiedy używać

- Chcesz pełnej kontroli nad hostingiem Git i CI/CD bez zależności od zewnętrznych usług.
- Potrzebujesz lekkiej platformy z PR-ami, rejestrem pakietów i Actions.
- Migrujesz workflowy z GitHub Actions (składnia jest zgodna).

## Przykład użycia

```yaml
# .gitea/workflows/build.yml — Gitea Actions
on: { push: { branches: [main] } }
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm run build
```

Runner (`act_runner`) wykonuje workflowy zupełnie jak GitHub Actions.

## Warto wiedzieć

- Świetnie łączy się z GitOps ([Argo CD](/katalog/argo-cd)/[Flux](/katalog/flux)) i CI ([Woodpecker](/katalog/woodpecker)).
- W EIAC to fundament: repo, PR-y i automaty publikacji żyją na Gitei.

---


## GitLab — SDLC / Policy-as-Code

URL: https://eiac.dev/katalog/gitlab
Repo: https://gitlab.com/gitlab-org/gitlab
Licencja: MIT

GitLab to kompletna platforma DevOps w jednym produkcie: hosting Git i merge requesty, pipeline'y CI/CD (definiowane w `.gitlab-ci.yml`), rejestr kontenerów i pakietów, skanowanie bezpieczeństwa, środowiska i wiele więcej. Można ją hostować samodzielnie (Community Edition na licencji MIT) lub korzystać z gitlab.com. Pipeline'y i konfiguracja żyją w repo, więc cały SDLC jest wersjonowany i powtarzalny.

## Kiedy używać

- Chcesz „wszystko w jednym" (SCM + CI/CD + rejestr + security) na własnej infrastrukturze.
- Potrzebujesz dojrzałych pipeline'ów jako kod (`.gitlab-ci.yml`) i środowisk.
- Standaryzujesz pracę wielu zespołów na jednej platformie.

## Przykład użycia

```yaml
# .gitlab-ci.yml
stages: [build, release]
build:
  image: node:20
  stage: build
  script: [npm ci, npm run build]
release:
  image: node:20
  stage: release
  rules: [{ if: '$CI_COMMIT_BRANCH == "main"' }]
  script: [npx semantic-release]
```

## Warto wiedzieć

- Lżejsza, minimalistyczna alternatywa do samego hostingu Git + CI: [Gitea](/katalog/gitea).
- Dobrze współgra z [semantic-release](/katalog/semantic-release) (wtyczka GitLab) i GitOps ([Argo CD](/katalog/argo-cd)/[Flux](/katalog/flux)).

---


## Gitleaks — Security-as-Code

URL: https://eiac.dev/katalog/gitleaks
Repo: https://github.com/gitleaks/gitleaks
Licencja: MIT

Gitleaks skanuje repozytoria i całą historię Git w poszukiwaniu przypadkowo zacommitowanych sekretów — kluczy API, tokenów, haseł. Działa lokalnie (hook pre-commit) i w CI jako bramka, a reguły wykrywania konfigurujesz deklaratywnie (TOML), z możliwością allowlist dla fałszywych alarmów. To prosta, wysokowartościowa warstwa „security-as-code".

## Kiedy używać

- Chcesz wyłapać sekrety zanim trafią do repo (pre-commit) lub w PR (CI).
- Audytujesz istniejącą historię Git pod kątem wycieków.
- Potrzebujesz konfigurowalnych reguł i allowlist.

## Przykład użycia

```bash
gitleaks detect --source . --redact       # skan repo + historii
gitleaks protect --staged                  # przed commitem
```

```yaml
# .gitea/workflows/security.yml (fragment)
- run: gitleaks detect --no-banner --exit-code 1
```

Niezerowy kod wyjścia zatrzymuje pipeline, gdy wykryto sekret.

## Warto wiedzieć

- Najlepiej działa jako hook pre-commit + bramka w Gitea Actions jednocześnie.
- Reguły i allowlist trzymaj w `.gitleaks.toml` w repo.

---


## gitsign — Security-as-Code

URL: https://eiac.dev/katalog/gitsign
Repo: https://github.com/sigstore/gitsign
Licencja: Apache-2.0

gitsign umożliwia podpisywanie commitów i tagów Git bez zarządzania długożyciowymi kluczami — wykorzystuje Sigstore (keyless): tożsamość OIDC, krótkożyciowy certyfikat i publiczny log przejrzystości (Rekor). Dzięki temu autentyczność historii repo staje się weryfikowalna i automatyzowalna, co wzmacnia bezpieczeństwo łańcucha dostaw oprogramowania.

## Kiedy używać

- Chcesz podpisywać commity bez utrzymywania kluczy GPG.
- Wzmacniasz integralność łańcucha dostaw (provenance).
- Weryfikujesz autentyczność commitów w CI.

## Przykład użycia

```bash
git config --local commit.gpgsign true
git config --local gpg.x509.program gitsign
git config --local gpg.format x509
git commit -m "feat: nowy wpis katalogu"   # podpis keyless przez Sigstore
```

## Warto wiedzieć

- Bezkluczowy model: tożsamość OIDC + krótkożyciowy cert + log Rekor.
- Element szerszego ekosystemu Sigstore (cosign) do podpisywania artefaktów.

---


## Grype — Security-as-Code

URL: https://eiac.dev/katalog/grype
Repo: https://github.com/anchore/grype
Licencja: Apache-2.0

Grype to szybki skaner podatności dla obrazów kontenerów i systemów plików. Świetnie współpracuje z Syft (generatorem SBOM) — najpierw tworzysz listę składników (SBOM), potem skanujesz ją pod kątem znanych CVE. Dzięki prostemu CLI i przewidywalnym kodom wyjścia łatwo wpina się w pipeline jako bramka jakości.

## Kiedy używać

- Skanujesz obrazy i artefakty pod kątem CVE w CI.
- Pracujesz w modelu SBOM-first (Syft → Grype).
- Chcesz lekkiego, szybkiego skanera obok [Trivy](/katalog/trivy).

## Przykład użycia

```bash
grype ghcr.io/eiac/web:1.0.0                 # skan obrazu
syft ghcr.io/eiac/web:1.0.0 -o spdx-json | grype   # ze SBOM
```

```yaml
# fail przy wysokiej severity
- run: grype ghcr.io/eiac/web:1.0.0 --fail-on high
```

## Warto wiedzieć

- Syft + Grype rozdzielają „co jest w artefakcie" od „co jest podatne".
- Komplementarny do [Trivy](/katalog/trivy) — część zespołów uruchamia oba.

---


## Harbor — SDLC / Policy-as-Code

URL: https://eiac.dev/katalog/harbor
Repo: https://github.com/goharbor/harbor
Licencja: Apache-2.0

Harbor to otwarty, samodzielnie hostowany rejestr obrazów kontenerów i artefaktów OCI z funkcjami bezpieczeństwa łańcucha dostaw: skanowaniem podatności, podpisywaniem, politykami replikacji i kontrolą dostępu (RBAC). Konfigurację projektów i polityk utrzymujesz deklaratywnie, więc dystrybucja artefaktów staje się audytowalnym elementem pipeline'u.

## Kiedy używać

- Potrzebujesz własnego rejestru obrazów/artefaktów z kontrolą dostępu.
- Chcesz skanu CVE i podpisywania artefaktów przy publikacji.
- Replikujesz obrazy między środowiskami/regionami.

## Przykład użycia

```bash
docker tag eiac/web registry.eiac.dev/eiac/web:1.0.0
docker push registry.eiac.dev/eiac/web:1.0.0
# Harbor automatycznie skanuje obraz i blokuje pull przy krytycznych CVE (polityka)
```

## Warto wiedzieć

- Wbudowane skanowanie integruje silniki takie jak [Trivy](/katalog/trivy)/[Grype](/katalog/grype).
- Polityki „prevent vulnerable images from running" to bramka bezpieczeństwa w dostawie.

---


## Harness Open Source — SDLC / Policy-as-Code

URL: https://eiac.dev/katalog/harness
Repo: https://github.com/harness/harness
Licencja: Apache-2.0

Harness Open Source to kompletna, samodzielnie hostowana platforma dla zespołów: hosting repozytoriów (SCM), pipeline'y CI/CD, hostowane środowiska deweloperskie i rejestry artefaktów — w jednym miejscu. Pipeline'y i konfigurację opisujesz deklaratywnie, więc cały cykl wytwarzania (od kodu po artefakt) jest wersjonowany i powtarzalny.

## Kiedy używać

- Chcesz jednej, otwartej platformy zamiast sklejać osobne narzędzia.
- Potrzebujesz SCM + CI/CD + rejestru artefaktów u siebie.
- Standaryzujesz workflow zespołów end-to-end.

## Przykład użycia

```yaml
# .harness/pipeline.yml (skrót)
pipeline:
  stages:
    - stage:
        name: build
        spec:
          steps:
            - step: { type: Run, spec: { command: "npm ci && npm run build" } }
```

## Warto wiedzieć

- Konkuruje zakresowo z platformami typu GitLab; w EIAC repo trzymamy na Gitei, więc traktuj Harness jako opcję „wszystko w jednym".
- Open Source to rdzeń; część funkcji enterprise jest płatna.

---


## Helm — App-as-Code

URL: https://eiac.dev/katalog/helm
Repo: https://github.com/helm/helm
Licencja: Apache-2.0

Helm to menedżer pakietów dla Kubernetes. Aplikacje i ich zależności pakujesz w „charty" — szablonowane manifesty z parametrami (`values.yaml`), które instalujesz, aktualizujesz i wycofujesz jako jedną, wersjonowaną jednostkę (release). Dzięki temu to samo wdrożenie powtarzasz w wielu środowiskach, zmieniając tylko wartości.

## Kiedy używać

- Wdrażasz aplikacje na Kubernetes i chcesz je wersjonować oraz łatwo wycofywać.
- Parametryzujesz to samo wdrożenie dla dev/stage/prod przez `values`.
- Korzystasz z gotowych chartów (bazy, ingress, narzędzia) z repozytoriów.

## Przykład użycia

```bash
helm repo add bitnami https://charts.bitnami.com/bitnami
helm install web bitnami/nginx -f values.prod.yaml
helm upgrade web bitnami/nginx --set replicaCount=3
helm rollback web 1   # powrót do poprzedniej wersji
```

Szablony chartu używają wartości, np. `replicas: {{ .Values.replicaCount }}`.

## Warto wiedzieć

- Często łączony z [Argo CD](/katalog/argo-cd) w podejściu GitOps.
- Trzymaj `values` w repo — to one są „kodem" wdrożenia.

---


## Infisical — Security-as-Code

URL: https://eiac.dev/katalog/infisical
Repo: https://github.com/Infisical/infisical
Licencja: MIT

Infisical to otwarta platforma do zarządzania sekretami z naciskiem na DX: synchronizuje sekrety między środowiskami, integruje się z CI/CD i Kubernetes, wykrywa wycieki i obsługuje certyfikaty oraz dostęp uprzywilejowany. Sekrety i ich konfigurację trzymasz scentralizowanie, a aplikacje pobierają je w runtime — zamiast plików `.env` w repo.

## Kiedy używać

- Chcesz przyjaznej deweloperom alternatywy do zarządzania sekretami.
- Synchronizujesz sekrety do CI/CD, Kubernetes i lokalnego dev.
- Potrzebujesz wykrywania wycieków i zarządzania certyfikatami w jednym.

## Przykład użycia

```bash
infisical login
infisical run -- npm start     # wstrzykuje sekrety do procesu
infisical secrets set DB_URL="postgres://…" --env=prod
```

## Warto wiedzieć

- Lżejsza, „produktowa" alternatywa do [Vault](/katalog/vault)/[OpenBao](/katalog/openbao).
- Można hostować samodzielnie (open source) lub korzystać z chmury.

---


## Istio — App-as-Code

URL: https://eiac.dev/katalog/istio
Repo: https://github.com/istio/istio
Licencja: Apache-2.0

Istio to service mesh dla Kubernetes, który dodaje warstwę sieciową między usługami: szyfrowanie mTLS, sterowanie ruchem (routing, canary, retry), polityki dostępu i pełną obserwowalność — bez zmian w kodzie aplikacji. Wszystko konfigurujesz deklaratywnie przez obiekty Kubernetes (CRD), więc zachowanie sieci między usługami staje się wersjonowanym kodem.

## Kiedy używać

- Masz wiele usług i potrzebujesz mTLS, routingu i polityk bez zmian w kodzie.
- Robisz zaawansowane wdrożenia (canary, mirroring, A/B).
- Chcesz spójnej obserwowalności ruchu między usługami.

## Przykład użycia

```yaml
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata: { name: web }
spec:
  hosts: [web]
  http:
    - route:
        - { destination: { host: web, subset: v1 }, weight: 90 }
        - { destination: { host: web, subset: v2 }, weight: 10 }
```

## Warto wiedzieć

- Bogaty, ale cięższy od lekkich meshy jak [Linkerd](/katalog/linkerd).
- Działa na [Kubernetes](/katalog/kubernetes); polityki wersjonujesz jak manifesty.

---


## k3s — App-as-Code

URL: https://eiac.dev/katalog/k3s
Repo: https://github.com/k3s-io/k3s
Licencja: Apache-2.0

k3s to certyfikowana, odchudzona dystrybucja Kubernetes spakowana w jedno binarium (<100 MB), z rozsądnymi domyślnymi ustawieniami. Idealna na edge, IoT, CI i małe serwery, gdzie pełny klaster byłby przesadą — a jednocześnie w pełni zgodna z [Kubernetes](/katalog/kubernetes), więc te same manifesty działają bez zmian. Klaster stawiasz jednym poleceniem i opisujesz deklaratywnie jak każdy k8s.

## Kiedy używać

- Potrzebujesz lekkiego Kubernetes na brzegu sieci, w CI lub homelab.
- Chcesz pełnej zgodności z k8s przy minimalnym narzucie.
- Stawiasz klastry szybko i powtarzalnie (skrypt/IaC).

## Przykład użycia

```bash
curl -sfL https://get.k3s.io | sh -      # serwer (control plane)
sudo k3s kubectl get nodes
# dołączenie agenta:
curl -sfL https://get.k3s.io | K3S_URL=https://server:6443 K3S_TOKEN=… sh -
```

## Warto wiedzieć

- Te same manifesty/[Helm](/katalog/helm) co na „dużym" k8s — bez zmian.
- Świetnie nadaje się pod GitOps ([Flux](/katalog/flux)/[Argo CD](/katalog/argo-cd)).

---


## kind — App-as-Code

URL: https://eiac.dev/katalog/kind
Repo: https://github.com/kubernetes-sigs/kind
Licencja: Apache-2.0

kind (Kubernetes IN Docker) uruchamia pełny klaster Kubernetes w kontenerach Dockera — idealnie do testów i CI. Konfigurację klastra (liczba węzłów, wersja, porty) opisujesz w pliku YAML, więc te same, powtarzalne klastry stawiasz lokalnie i w pipeline. To standard do testowania manifestów, operatorów i całych wdrożeń przed produkcją.

## Kiedy używać

- Testujesz manifesty/Helm/operatory w CI na prawdziwym k8s API.
- Chcesz szybkich, jednorazowych klastrów lokalnie.
- Reprodukujesz środowisko k8s deterministycznie.

## Przykład użycia

```yaml
# kind.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes: [{ role: control-plane }, { role: worker }, { role: worker }]
```

```bash
kind create cluster --config kind.yaml
kubectl apply -k overlays/dev
kind delete cluster
```

## Warto wiedzieć

- Świetny do bramek „deploy test" w [Gitea](/katalog/gitea) Actions/CI.
- Do trwałych, lekkich klastrów wybierz [k3s](/katalog/k3s).

---


## Knative — App-as-Code

URL: https://eiac.dev/katalog/knative
Repo: https://github.com/knative/serving
Licencja: Apache-2.0

Knative dodaje do Kubernetes model serverless: usługi skalują się automatycznie wraz z ruchem, aż do zera, gdy nie ma żądań. Aplikację opisujesz jednym deklaratywnym obiektem (Service), a Knative zarządza wersjami, ruchem i autoskalowaniem. To sposób na uruchamianie aplikacji „na żądanie" przy zachowaniu pełni ekosystemu k8s.

## Kiedy używać

- Chcesz serverless (scale-to-zero) na własnym klastrze [Kubernetes](/katalog/kubernetes).
- Masz zmienny ruch i zależy Ci na oszczędności zasobów.
- Potrzebujesz prostego wdrażania wersji i podziału ruchu.

## Przykład użycia

```yaml
apiVersion: serving.knative.dev/v1
kind: Service
metadata: { name: web }
spec:
  template:
    spec:
      containers:
        - image: ghcr.io/eiac/web:1.0.0
```

Knative samo skaluje `web` od zera w górę zależnie od ruchu.

## Warto wiedzieć

- Łączy się z service mesh ([Istio](/katalog/istio)/[Linkerd](/katalog/linkerd)) do routingu.
- Dobrze pasuje do GitOps ([Argo CD](/katalog/argo-cd)/[Flux](/katalog/flux)).

---


## kOps — Infrastructure-as-Code

URL: https://eiac.dev/katalog/kops
Repo: https://github.com/kubernetes/kops
Licencja: Apache-2.0

kOps (Kubernetes Operations) provisionuje i utrzymuje produkcyjne klastry Kubernetes z deklaratywnej specyfikacji. Opisujesz pożądany stan klastra (wersja, grupy węzłów, sieć), a kOps tworzy, aktualizuje i skaluje całą infrastrukturę — łącznie z generowaniem manifestów lub kodu Terraform. Cały cykl życia klastra staje się wersjonowanym kodem.

## Kiedy używać

- Stawiasz i utrzymujesz pełne klastry k8s (głównie AWS, też inne).
- Chcesz deklaratywnej specyfikacji klastra i powtarzalnych aktualizacji.
- Wolisz generowanie planu/Terraform zamiast ręcznej konfiguracji.

## Przykład użycia

```bash
kops create cluster --name eiac.k8s.local --zones eu-central-1a --node-count 3
kops update cluster --name eiac.k8s.local --yes    # provisioning
kops edit cluster eiac.k8s.local                    # zmiana specyfikacji
kops rolling-update cluster --yes                    # bezpieczna aktualizacja
```

## Warto wiedzieć

- Może generować [Terraform](/katalog/terraform) zamiast działać bezpośrednio.
- Alternatywa oparta o Ansible na dowolnych hostach: [Kubespray](/katalog/kubespray).

---


## kube-bench — Security-as-Code

URL: https://eiac.dev/katalog/kube-bench
Repo: https://github.com/aquasecurity/kube-bench
Licencja: Apache-2.0

kube-bench sprawdza, czy klaster Kubernetes jest skonfigurowany zgodnie z najlepszymi praktykami z CIS Kubernetes Benchmark. Uruchamiasz go jako zadanie w klastrze, a wynik to zestaw testów (pass/fail/warn) z konkretnymi zaleceniami. Konfiguracja testów jest deklaratywna (YAML), więc audyt zgodności sam staje się kodem — powtarzalnym i wersjonowanym.

## Kiedy używać

- Audytujesz hardening klastra [Kubernetes](/katalog/kubernetes) wg uznanego standardu.
- Chcesz powtarzalnego raportu zgodności (np. cyklicznie w CI/cronie).
- Przygotowujesz się do wymagań compliance.

## Przykład użycia

```bash
# jako Job w klastrze
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
kubectl logs job/kube-bench
```

```text
[PASS] 1.2.1 Ensure that the --anonymous-auth argument is set to false
[FAIL] 1.2.6 Ensure that the --kubelet-certificate-authority is set
```

## Warto wiedzieć

- Uzupełnia skan manifestów ([Checkov](/katalog/checkov)) o audyt działającego klastra.
- Wyniki łatwo kierować do raportu lub bramki w pipeline.

---


## Kubernetes — App-as-Code

URL: https://eiac.dev/katalog/kubernetes
Repo: https://github.com/kubernetes/kubernetes
Licencja: Apache-2.0

Kubernetes to standard orkiestracji kontenerów: deklarujesz pożądany stan aplikacji (ile replik, jakie zasoby, jak sieć), a klaster nieustannie utrzymuje ten stan — restartuje padnięte pody, skaluje i wdraża nowe wersje. To fundament „App-as-Code": całe środowisko uruchomieniowe opisujesz w wersjonowanych manifestach YAML.

## Kiedy używać

- Uruchamiasz wiele usług/kontenerów i potrzebujesz skalowania oraz samonaprawiania.
- Chcesz deklaratywnie opisać runtime i wdrażać przez GitOps.
- Standaryzujesz platformę pod wiele zespołów i środowisk.

## Przykład użycia

```yaml
apiVersion: apps/v1
kind: Deployment
metadata: { name: web }
spec:
  replicas: 3
  selector: { matchLabels: { app: web } }
  template:
    metadata: { labels: { app: web } }
    spec:
      containers:
        - name: web
          image: ghcr.io/eiac/web:1.0.0
          ports: [{ containerPort: 8080 }]
```

```bash
kubectl apply -f deployment.yaml
kubectl get pods -l app=web
```

## Warto wiedzieć

- Manifesty szablonuj przez [Helm](/katalog/helm) lub [Kustomize](/katalog/kustomize).
- Wdrażaj deklaratywnie z Gita przez [Argo CD](/katalog/argo-cd).

---


## Kubescape — Security-as-Code

URL: https://eiac.dev/katalog/kubescape
Repo: https://github.com/kubescape/kubescape
Licencja: Apache-2.0

Kubescape to otwarta platforma bezpieczeństwa Kubernetes działająca w IDE, CI/CD i w klastrze. Skanuje manifesty i klaster pod kątem błędów konfiguracji, analizuje ryzyko i sprawdza zgodność z ramami takimi jak NSA-CISA czy MITRE ATT&CK. Wyniki i polityki są deklaratywne, więc bezpieczeństwo k8s staje się powtarzalną bramką, a nie jednorazowym audytem.

## Kiedy używać

- Skanujesz manifesty/klaster [Kubernetes](/katalog/kubernetes) pod kątem misconfig i ryzyka.
- Chcesz zgodności z uznanymi ramami (NSA-CISA, MITRE) w CI.
- Potrzebujesz jednego narzędzia od IDE po klaster.

## Przykład użycia

```bash
kubescape scan --format json --output res.json        # cały klaster/manifesty
kubescape scan framework nsa                            # konkretne ramy
kubescape scan . --severity-threshold high              # bramka w CI
```

## Warto wiedzieć

- Uzupełnia [kube-bench](/katalog/kube-bench) (CIS) o szersze ramy i analizę ryzyka.
- Egzekwowanie w klastrze realizujesz przez [OPA Gatekeeper](/katalog/gatekeeper).

---


## Kubespray — Infrastructure-as-Code

URL: https://eiac.dev/katalog/kubespray
Repo: https://github.com/kubernetes-sigs/kubespray
Licencja: Apache-2.0

Kubespray wdraża produkcyjne klastry Kubernetes na dowolnej infrastrukturze (bare metal, VM, chmura) za pomocą [Ansible](/katalog/ansible). Konfigurację klastra trzymasz w plikach inventory i zmiennych, a playbooki idempotentnie instalują i aktualizują wszystkie komponenty. To podejście „cluster-as-code" niezależne od dostawcy — ten sam kod stawia klaster wszędzie.

## Kiedy używać

- Stawiasz k8s na własnych serwerach/bare metal lub wielu chmurach.
- Już używasz Ansible i chcesz spójnego, idempotentnego provisioningu.
- Zależy Ci na niezależności od konkretnego dostawcy.

## Przykład użycia

```bash
# inventory + zmienne opisują klaster
ansible-playbook -i inventory/eiac/hosts.yaml cluster.yml
ansible-playbook -i inventory/eiac/hosts.yaml upgrade-cluster.yml
```

## Warto wiedzieć

- Inventory i zmienne trzymaj w repo (Gitea) — to one są „kodem" klastra.
- Alternatywa z własnym modelem stanu/chmurowym: [kOps](/katalog/kops).

---


## KubeVirt — App-as-Code

URL: https://eiac.dev/katalog/kubevirt
Repo: https://github.com/kubevirt/kubevirt
Licencja: Apache-2.0

KubeVirt pozwala uruchamiać i zarządzać maszynami wirtualnymi obok kontenerów, w tym samym klastrze Kubernetes. VM definiujesz jako obiekty Kubernetes (CRD), więc korzystają z tego samego deklaratywnego API, GitOps i narzędzi co reszta workloadów. To sposób na włączenie „starszych" obciążeń wymagających pełnego systemu do platformy opartej na kodzie.

## Kiedy używać

- Masz workloady, które muszą działać jako VM, ale chcesz nimi zarządzać jak k8s.
- Konsolidujesz kontenery i VM-y na jednej platformie.
- Chcesz VM-y pod GitOps (deklaratywnie, w repo).

## Przykład użycia

```yaml
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata: { name: eiac-vm }
spec:
  running: true
  template:
    spec:
      domain:
        resources: { requests: { memory: 1Gi } }
```

```bash
kubectl apply -f vm.yaml
kubectl get vms
```

## Warto wiedzieć

- Działa na [Kubernetes](/katalog/kubernetes); VM-y wersjonujesz jak każdy manifest.
- Wymaga wsparcia wirtualizacji na węzłach (KVM).

---


## Kustomize — App-as-Code

URL: https://eiac.dev/katalog/kustomize
Repo: https://github.com/kubernetes-sigs/kustomize
Licencja: Apache-2.0

Kustomize to bezszablonowy sposób na dostosowywanie manifestów Kubernetes. Zamiast szablonów z parametrami trzymasz bazowe manifesty i nakładasz na nie „overlays" — łatki dla konkretnych środowisk (dev/prod). Jest wbudowany w `kubectl`, więc nie wymaga dodatkowych narzędzi, a wynik to czysty YAML.

## Kiedy używać

- Chcesz wariantów wdrożenia (środowiska) bez logiki szablonów.
- Wolisz patche YAML zamiast `values` jak w [Helm](/katalog/helm).
- Trzymasz bazę + nakładki w Gicie pod GitOps.

## Przykład użycia

```yaml
# overlays/prod/kustomization.yaml
resources: [../../base]
replicas:
  - name: web
    count: 5
images:
  - name: ghcr.io/eiac/web
    newTag: 1.0.0
```

```bash
kubectl apply -k overlays/prod
```

## Warto wiedzieć

- Wbudowany w `kubectl` (`-k`); zero dodatkowych zależności.
- Często łączony z [Argo CD](/katalog/argo-cd); bywa stosowany razem z Helm.

---


## Kyverno — Security-as-Code

URL: https://eiac.dev/katalog/kyverno
Repo: https://github.com/kyverno/kyverno
Licencja: Apache-2.0

Kyverno to silnik polityk zaprojektowany specjalnie dla Kubernetes. W odróżnieniu od [OPA](/katalog/open-policy-agent)/[Gatekeeper](/katalog/gatekeeper) nie wymaga uczenia się osobnego języka (Rego) — polityki pisze się jako zwykłe **zasoby Kubernetes w YAML**. Działa jako admission controller: potrafi walidować, mutować, generować zasoby oraz weryfikować podpisy obrazów, egzekwując reguły zanim cokolwiek trafi do klastra.

## Kiedy używać

- Chcesz policy-as-code dla Kubernetes bez wprowadzania nowego języka (zostajesz w YAML).
- Potrzebujesz nie tylko walidacji, ale też mutacji i generowania zasobów (np. domyślne sieci, limity, labelki).
- Egzekwujesz reguły w klastrze (admission) i/lub skanujesz manifesty w CI.

## Przykład użycia

```yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata: { name: require-non-root }
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-runAsNonRoot
      match: { any: [{ resources: { kinds: ["Pod"] } }] }
      validate:
        message: "kontener musi działać jako non-root"
        pattern:
          spec:
            securityContext:
              runAsNonRoot: true
```

```bash
# ta sama polityka jako bramka w CI (bez klastra)
kyverno apply policy/ --resource manifests/
```

## Warto wiedzieć

- Projekt CNCF; naturalny wybór, gdy zespół woli YAML zamiast Rego z [OPA](/katalog/open-policy-agent).
- Uzupełnia skanery jak [Checkov](/katalog/checkov)/[Trivy](/katalog/trivy); w CI rolę testów konfiguracji pełni też [Conftest](/katalog/conftest).

---


## lego — Security-as-Code

URL: https://eiac.dev/katalog/lego
Repo: https://github.com/go-acme/lego
Licencja: MIT

lego to klient ACME (Let's Encrypt i inne CA) oraz biblioteka w Go do automatycznego wydawania i odnawiania certyfikatów TLS. Obsługuje walidację DNS-01 dla dziesiątek dostawców DNS, więc certyfikaty (także wildcard) zdobywasz bez ręcznych kroków. Cykl życia certyfikatu staje się elementem automatyzacji — skryptu lub joba w CI/cronie.

## Kiedy używać

- Automatyzujesz wydawanie/odnawianie certyfikatów TLS poza serwerem WWW.
- Potrzebujesz wildcardów przez walidację DNS-01.
- Wbudowujesz logikę certyfikatów w pipeline lub własne narzędzie (biblioteka Go).

## Przykład użycia

```bash
lego --email ops@eiac.dev \
  --dns cloudflare \
  --domains "*.eiac.dev" \
  run
```

```bash
# odnowienie w cronie / Gitea Actions
lego --email ops@eiac.dev --dns cloudflare --domains "*.eiac.dev" renew
```

## Warto wiedzieć

- Świetny, gdy TLS kończy poza reverse proxy (np. dla usług wewnętrznych, [Nebula](/katalog/nebula)).
- Jako biblioteka Go pozwala wpiąć ACME we własne narzędzia.

---


## Linkerd — App-as-Code

URL: https://eiac.dev/katalog/linkerd
Repo: https://github.com/linkerd/linkerd2
Licencja: Apache-2.0

Linkerd to ultralekki, stawiający na bezpieczeństwo service mesh dla Kubernetes. Automatycznie włącza mTLS między usługami, dodaje metryki „golden signals" i niezawodność (retry, timeouty), zachowując minimalny narzut i prostotę obsługi. Konfiguracja jest deklaratywna (CRD/adnotacje), więc bezpieczna komunikacja między usługami staje się domyślna i wersjonowana.

## Kiedy używać

- Chcesz mTLS i metryk między usługami przy minimalnym narzucie.
- Wolisz prostotę i niski koszt operacyjny zamiast pełni funkcji.
- Zależy Ci na „zero-config" bezpieczeństwie komunikacji.

## Przykład użycia

```bash
linkerd install | kubectl apply -f -          # instalacja mesh
kubectl annotate ns web linkerd.io/inject=enabled
linkerd viz dashboard                          # metryki ruchu
```

## Warto wiedzieć

- Prostszy i lżejszy niż [Istio](/katalog/istio) — mniej funkcji, mniej narzutu.
- mTLS działa domyślnie po wstrzyknięciu proxy do namespace.

---


## Longhorn — App-as-Code

URL: https://eiac.dev/katalog/longhorn
Repo: https://github.com/longhorn/longhorn
Licencja: Apache-2.0

Longhorn to lekki, rozproszony storage blokowy zbudowany dla Kubernetes. Dostarcza trwałe wolumeny z replikacją, snapshotami i backupami — wszystko zarządzane deklaratywnie przez Kubernetes (StorageClass, PVC, CRD). Stan i polityki przechowywania danych stają się częścią kodu klastra, bez zależności od storage konkretnej chmury.

## Kiedy używać

- Potrzebujesz trwałego storage'u na własnym klastrze (bare metal, edge).
- Chcesz replikacji, snapshotów i backupów zarządzanych deklaratywnie.
- Unikasz vendor lock-in storage chmurowego.

## Przykład użycia

```yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata: { name: longhorn }
provisioner: driver.longhorn.io
parameters: { numberOfReplicas: "3" }
```

PVC z `storageClassName: longhorn` dostaje replikowany, trwały wolumen.

## Warto wiedzieć

- Projekt CNCF; dobrze pasuje do lekkich klastrów ([k3s](/katalog/k3s)).
- Backupy wolumenów uzupełnia backup całych aplikacji ([Velero](/katalog/velero)).

---


## MegaLinter — SDLC / Policy-as-Code

URL: https://eiac.dev/katalog/megalinter
Repo: https://github.com/oxsecurity/megalinter
Licencja: AGPL-3.0

MegaLinter uruchamia w jednym kroku CI dziesiątki linterów i skanerów dla wielu języków i formatów — od stylu kodu, przez literówki, po skany bezpieczeństwa i sekretów. Konfigurację trzymasz deklaratywnie w repo, a narzędzie raportuje problemy (i potrafi auto-naprawiać część z nich). To wygodny „pojedynczy punkt wejścia" do jakości i higieny repozytorium.

## Kiedy używać

- Chcesz jednego kroku CI obejmującego lint, formatowanie i podstawowe skany security.
- Pracujesz w repo wielojęzycznym i nie chcesz konfigurować każdego lintera osobno.
- Zależy Ci na auto-naprawach i spójnym raporcie w PR.

## Przykład użycia

```yaml
# .mega-linter.yml
APPLY_FIXES: all
DISABLE: [SPELL]
ENABLE: [REPOSITORY_GITLEAKS, REPOSITORY_TRIVY]
```

```yaml
# krok w Gitea Actions (obraz MegaLinter)
- uses: oxsecurity/megalinter@v8
```

## Warto wiedzieć

- Pod spodem korzysta m.in. z [Gitleaks](/katalog/gitleaks) i [Trivy](/katalog/trivy) — wygodne, gdy chcesz wszystko naraz.
- Do dedykowanych, „twardych" bramek lepiej wołać konkretne narzędzia osobno.

---


## Nebula — Security-as-Code

URL: https://eiac.dev/katalog/nebula
Repo: https://github.com/slackhq/nebula
Licencja: MIT

Nebula to skalowalna sieć overlay (mesh VPN) z naciskiem na wydajność, prostotę i bezpieczeństwo. Tożsamość hostów opiera o certyfikaty, a reguły dostępu (firewall, grupy) definiujesz deklaratywnie w plikach konfiguracyjnych — sieć i jej polityki bezpieczeństwa stają się kodem, wersjonowanym i powtarzalnym. Świetnie sprawdza się do łączenia maszyn między chmurami i lokacjami.

## Kiedy używać

- Łączysz hosty z wielu chmur/lokacji w jedną, szyfrowaną sieć.
- Chcesz mikrosegmentacji i reguł dostępu jako konfiguracji.
- Zależy Ci na wydajnym, prostym mesh zamiast ciężkiego VPN.

## Przykład użycia

```yaml
# config.yml (fragment) — reguły firewalla per grupa
firewall:
  inbound:
    - port: 443
      proto: tcp
      groups: [web]
    - port: any
      proto: icmp
      host: any
```

```bash
nebula -config config.yml
```

## Warto wiedzieć

- Tożsamość przez certyfikaty (CA) — wydawanie i rotację automatyzujesz w CI.
- Konfiguracja per host w repo = audytowalna, powtarzalna topologia.

---


## Nitric — App-as-Code

URL: https://eiac.dev/katalog/nitric
Repo: https://github.com/nitrictech/nitric
Licencja: Apache-2.0

Nitric to **wielojęzyczny framework** (TypeScript, Python, Go i inne), który realizuje infrastructure-from-code w sposób celowo *uzupełniający* klasyczne IaC, a nie zastępujący je. Piszesz kod aplikacji i deklarujesz jej wymagania (np. „potrzebuję kolejki", „bucketa", „API"), a Nitric **wywodzi z tego specyfikację wymagań** i przekazuje ją pluginom wdrożeniowym, które generują konfigurację przez [Pulumi](/katalog/pulumi) lub [Terraform](/katalog/terraform). Dzięki temu IaC pozostaje w synchronizacji z aplikacją, a Ty nie piszesz go ręcznie. Nitric odcina aplikację od konkretnej chmury — ten sam kod wdrożysz na AWS, Azure, GCP czy [Kubernetes](/katalog/kubernetes).

## Kiedy używać

- Chcesz wygody infrastructure-from-code, ale **bez utraty kontroli** — pod spodem zostaje jawny Terraform/Pulumi, który możesz podejrzeć i dostroić.
- Zależy Ci na przenośności między chmurami i automatyzacji uprawnień (least privilege generowany z wymagań).
- Piszesz w różnych językach i potrzebujesz jednego modelu dla całego zespołu.

## Przykład użycia

```typescript
import { api, bucket } from '@nitric/sdk';

// wymaganie infrastruktury wywnioskowane z kodu
const images = bucket('images').allow('read', 'write');

api('public').get('/img/:name', async (ctx) => {
  const img = await images.file(ctx.req.params.name).read();
  ctx.res.body = img;
});
```

## Warto wiedzieć

- Architektura pluginowa: domyślnie deployment przez [Pulumi](/katalog/pulumi)/[Terraform](/katalog/terraform), ale możesz napisać własny plugin.
- Świadomie *dopełnia* IaC (utrzymuje je w synchronizacji z kodem), w odróżnieniu od [Encore](/katalog/encore), który separację aplikacja–infrastruktura znosi całkowicie; szerzej: [IaC w 2026](/blog/iac-2026-przeglad).
- Otwarty (Apache-2.0) i self-hostowalny — pasuje do podejścia „w Twoim CI, z Twoim stanem".

---


## Nix — Infrastructure-as-Code

URL: https://eiac.dev/katalog/nix
Repo: https://github.com/NixOS/nix
Licencja: LGPL-2.1

Nix to menedżer pakietów i system buildów oparty na czystych, deklaratywnych wyrażeniach. Każdy artefakt jest funkcją swoich wejść, więc buildy są powtarzalne i izolowane — to samo wejście zawsze daje ten sam wynik, niezależnie od maszyny. Z `flakes` opisujesz środowiska deweloperskie, pakiety i całe systemy (NixOS) w jednym, wersjonowanym pliku.

## Kiedy używać

- Chcesz identycznych środowisk dev/CI/prod, bez „u mnie działa".
- Potrzebujesz powtarzalnych, audytowalnych buildów.
- Zarządzasz wieloma toolchainami bez konfliktów wersji.

## Przykład użycia

```nix
# flake.nix — środowisko deweloperskie
{
  outputs = { self, nixpkgs }: {
    devShells.x86_64-linux.default =
      with nixpkgs.legacyPackages.x86_64-linux;
      mkShell { packages = [ nodejs_20 git ]; };
  };
}
```

```bash
nix develop   # wchodzisz w powłokę z dokładnie tymi narzędziami
```

## Warto wiedzieć

- Krzywa wejścia jest stroma, ale powtarzalność jest bezkonkurencyjna.
- `flakes` to dziś de facto standard; przypina wersje przez `flake.lock`.

---


## OPA Gatekeeper — Security-as-Code

URL: https://eiac.dev/katalog/gatekeeper
Repo: https://github.com/open-policy-agent/gatekeeper
Licencja: Apache-2.0

Gatekeeper to kontroler polityk dla Kubernetes oparty o [Open Policy Agent](/katalog/open-policy-agent). Działa jako admission webhook: zanim zasób trafi do klastra, sprawdza go względem polityk (ConstraintTemplate + Constraint) i odrzuca naruszenia. Polityki są deklaratywne (Rego), wersjonowane i audytowalne — to guardrails dla całego klastra „as-code".

## Kiedy używać

- Chcesz egzekwować reguły (np. wymagane labelki, zakaz `latest`, limity) na poziomie klastra.
- Standaryzujesz guardrails dla wielu zespołów/namespace'ów.
- Wolisz polityki w Rego, spójne z ekosystemem OPA.

## Przykład użycia

```yaml
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata: { name: must-have-owner }
spec:
  match: { kinds: [{ apiGroups: [""], kinds: ["Namespace"] }] }
  parameters: { labels: ["owner"] }
```

Próba utworzenia namespace bez `owner` zostanie odrzucona.

## Warto wiedzieć

- Statyczne sprawdzanie tych samych reguł w CI realizuje [Conftest](/katalog/conftest).
- Alternatywa trzymająca polityki w YAML (bez Rego): [Kyverno](/katalog/kyverno).
- Wykrywanie ryzyka uzupełnia [Kubescape](/katalog/kubescape).

---


## Open Policy Agent — SDLC / Policy-as-Code

URL: https://eiac.dev/katalog/open-policy-agent
Repo: https://github.com/open-policy-agent/opa
Licencja: Apache-2.0

Open Policy Agent (OPA) to uniwersalny silnik polityk, który oddziela decyzje autoryzacyjne i zgodności od kodu aplikacji. Reguły piszesz w języku Rego, a OPA odpowiada na pytania „czy to działanie jest dozwolone?" na podstawie danych wejściowych. Tę samą politykę można egzekwować w pipeline CI, w Kubernetes (Gatekeeper), w API gateway czy w samej aplikacji.

## Kiedy używać

- Chcesz spójnie egzekwować zasady bezpieczeństwa/zgodności w wielu miejscach.
- Polityka ma być testowalna, wersjonowana i recenzowana jak kod.
- Bramkujesz PR-y, manifesty Kubernetes albo plan Terraform.

## Przykład użycia

```rego
package eiac.authz

default allow := false

allow if {
  input.method == "GET"
  startswith(input.path, "/public/")
}
```

```bash
opa eval -d policy.rego -i input.json "data.eiac.authz.allow"
opa test .   # testy jednostkowe polityk
```

## Warto wiedzieć

- Z Conftest sprawdzisz pliki konfiguracyjne (YAML/JSON/HCL) w CI.
- W Kubernetes popularny przez OPA Gatekeeper (admission control).

---


## OpenBao — Security-as-Code

URL: https://eiac.dev/katalog/openbao
Repo: https://github.com/openbao/openbao
Licencja: MPL-2.0

OpenBao to społecznościowy fork [Vault](/katalog/vault) pod skrzydłami Linux Foundation, powstały po zmianie licencji HashiCorp na BUSL. Zachowuje zgodność z API, silnikami sekretów i CLI Vaulta, więc dla większości wdrożeń jest niemal drop-in, a rozwija się jako projekt w pełni open source (MPL-2.0). Tak jak pierwowzór: centralizuje sekrety, generuje je dynamicznie i szyfruje dane jako usługa.

## Kiedy używać

- Chcesz funkcji Vaulta, ale na licencji open source bez ograniczeń BUSL.
- Migrujesz istniejące wdrożenie Vault i zależy Ci na zgodności API/CLI.
- Wolisz projekt zarządzany przez fundację i społeczność.

## Przykład użycia

```bash
# CLI jest zgodne z Vault — często wystarczy zamiana binarki
bao kv put secret/eiac/db password="s3cret"
bao kv get -field=password secret/eiac/db
```

```hcl
# polityka dostępu jako kod (jak w Vault)
path "secret/data/eiac/*" {
  capabilities = ["read"]
}
```

## Warto wiedzieć

- Zgodność celowana w wersje Vault z okresu forka; najnowsze funkcje HashiCorp mogą się różnić.
- Provisioning zautomatyzujesz [Terraform](/katalog/terraform)/[OpenTofu](/katalog/opentofu).

---


## OpenTaco (Digger) — Infrastructure-as-Code

URL: https://eiac.dev/katalog/digger
Repo: https://github.com/diggerhq/digger
Licencja: Apache-2.0

OpenTaco to **open-source** następca projektu Digger (rebrand z listopada 2025, ten sam silnik). Uruchamia [Terraform](/katalog/terraform)/[OpenTofu](/katalog/opentofu) w Twoim istniejącym pipelinie CI, zamiast stawiać osobny serwer automatyzacji — komentuje plany w PR, zarządza blokadami stanu i kolejnością, egzekwuje polityki. Nowy kierunek to **state-first**: zarządzanie plikami stanu z kontrolą dostępu i historią wersji (interfejs zgodny z HCP Terraform), a docelowo samo-hostowalna alternatywa dla Terraform Cloud/Enterprise (zdalne uruchomienia, PR automation, drift).

## Kiedy używać

- Chcesz `plan`/`apply` w PR i zarządzanie stanem bez osobnego serwera (alternatywa dla Atlantis/TFC).
- Masz już CI (np. Gitea Actions) i wolisz trzymać tam orkiestrację oraz stan — po swojej stronie.
- Zależy Ci na otwartej, self-hostowalnej kategorii TACOS (kontrola, suwerenność).

## Przykład użycia

```yaml
# digger.yml
projects:
  - name: infra
    dir: infra
    workflow: default
workflows:
  default:
    plan: { steps: [init, plan] }
    apply: { steps: [init, apply] }
```

PR dostaje komentarz z planem; `apply` po zatwierdzeniu i merge.

## Warto wiedzieć

- Łączy się z politykami [Open Policy Agent](/katalog/open-policy-agent)/[Checkov](/katalog/checkov).
- Model „w Twoim CI, z Twoim stanem" wspiera [exit-by-design](/blog/suwerenny-idp-exit-by-design); w EIAC pasuje wprost do Gitea Actions.
- Komercyjne odpowiedniki: [Spacelift](/katalog/spacelift), [env0](/katalog/env0), [Scalr](/katalog/scalr); lekki orkiestrator open-source to [Terramate](/katalog/terramate).

---


## OpenTofu — Infrastructure-as-Code

URL: https://eiac.dev/katalog/opentofu
Repo: https://github.com/opentofu/opentofu
Licencja: MPL-2.0

OpenTofu to społecznościowy fork Terraform pod skrzydłami Linux Foundation, powstały po zmianie licencji HashiCorp na BUSL. Zachowuje zgodność z językiem HCL, formatem stanu i ekosystemem providerów, więc dla większości projektów jest niemal drop-in. Rozwija też własne funkcje, np. szyfrowanie stanu po stronie klienta.

## Kiedy używać

- Chcesz pozostać na licencji open source (MPL-2.0) bez ograniczeń BUSL.
- Migrujesz istniejący kod Terraform i zależy Ci na zgodności.
- Potrzebujesz funkcji jak natywne szyfrowanie stanu.

## Przykład użycia

```bash
# migracja z Terraform jest zwykle zamianą binarki
tofu init
tofu plan
tofu apply
```

Pliki `.tf`, moduły i providerzy działają bez zmian — różni się przede wszystkim komenda (`tofu` zamiast `terraform`).

## Warto wiedzieć

- Zgodność celowana w wersje Terraform z okresu forka; nowsze funkcje HashiCorp mogą się różnić.
- Wspierany przez wielu dostawców i zintegrowany z popularnymi platformami CI/CD.

---


## Ory Hydra — Security-as-Code

URL: https://eiac.dev/katalog/ory-hydra
Repo: https://github.com/ory/hydra
Licencja: Apache-2.0

Ory Hydra to certyfikowany serwer OAuth2 i OpenID Connect klasy „internet-scale". Jest headless — nie narzuca własnego UI ani bazy użytkowników, a integrujesz go ze swoim zarządzaniem tożsamością przez API. Klientów OAuth2, zakresy i polityki konfigurujesz deklaratywnie (pliki/API), więc tożsamość i dostęp stają się elementem infrastruktury jako kod.

## Kiedy używać

- Potrzebujesz własnego, zgodnego ze standardami dostawcy OAuth2/OIDC.
- Chcesz konfigurować klientów i przepływy deklaratywnie, nie klikać w panelu.
- Budujesz SSO/autoryzację dla wielu aplikacji i API.

## Przykład użycia

```bash
# rejestracja klienta OAuth2 z konfiguracji
hydra create client \
  --endpoint http://localhost:4445 \
  --grant-type client_credentials \
  --name eiac-ci
```

```yaml
# fragment konfiguracji serwera (hydra.yml)
urls:
  self:
    issuer: https://auth.eiac.dev
strategies:
  access_token: jwt
```

## Warto wiedzieć

- Headless: łączysz z własnym logowaniem/consent przez API.
- Do autoryzacji na poziomie aplikacji łącz z [Casbin](/katalog/casbin) lub [Open Policy Agent](/katalog/open-policy-agent).

---


## Penpot — Design-as-Code

URL: https://eiac.dev/katalog/penpot
Repo: https://github.com/penpot/penpot
Licencja: MPL-2.0

Penpot to otwarte (MPL-2.0) narzędzie do projektowania interfejsów i prototypowania, działające w przeglądarce i oparte na standardach (SVG/CSS). Jako jeden z nielicznych edytorów natywnie wspiera design tokeny i można je z niego eksportować, co czyni go naturalnym mostem między pracą projektanta a „design-as-code". Da się też hostować samodzielnie.

## Kiedy używać

- Chcesz otwartej alternatywy dla zamkniętych narzędzi, z możliwością self-hostingu.
- Projektujesz UI i chcesz utrzymywać tokeny blisko kodu.
- Zależy Ci na formatach zgodnych z webem (SVG/CSS).

## Przykład użycia

```text
1. Zdefiniuj tokeny (kolory, spacing) w panelu Tokens.
2. Wyeksportuj tokeny do JSON.
3. Podaj JSON jako źródło do Style Dictionary → tokens.css.
```

```bash
# self-hosting przez Docker Compose
docker compose -f docker-compose.yaml up -d
```

W ten sposób decyzje projektowe z Penpot trafiają do kodu jako wersjonowane tokeny.

## Warto wiedzieć

- Eksport tokenów dobrze łączy się ze [Style Dictionary](/katalog/style-dictionary).
- Pełnia funkcji rośnie szybko; sprawdź aktualny zakres przed migracją z innego narzędzia.

---


## promptfoo — Security-as-Code

URL: https://eiac.dev/katalog/promptfoo
Repo: https://github.com/promptfoo/promptfoo
Licencja: MIT

promptfoo to narzędzie do testowania, ewaluacji i red-teamingu aplikacji opartych o LLM — promptów, agentów i RAG-ów. Scenariusze testowe i asercje opisujesz deklaratywnie (YAML), a narzędzie porównuje modele, wykrywa regresje jakości oraz skanuje pod kątem podatności (np. prompt injection, wycieki). Bezpieczeństwo i jakość AI stają się powtarzalnym krokiem w pipeline, nie ręcznym sprawdzaniem.

## Kiedy używać

- Testujesz i porównujesz prompty/modele z asercjami w CI.
- Robisz red-teaming aplikacji LLM (injection, jailbreak, wycieki).
- Chcesz wykrywać regresje jakości przy zmianach promptów/modeli.

## Przykład użycia

```yaml
# promptfooconfig.yaml
prompts: ["Odpowiedz po polsku: {{pytanie}}"]
providers: [openai:gpt-4o, anthropic:claude-3-5-sonnet]
tests:
  - vars: { pytanie: "Czym jest IaC?" }
    assert:
      - type: contains
        value: "infrastruktura"
```

```bash
npx promptfoo eval        # ewaluacja
npx promptfoo redteam run # skan bezpieczeństwa
```

## Warto wiedzieć

- Configi trzymaj w repo — ewaluacja i red-teaming jako bramka w Gitea Actions.
- Wspiera wielu dostawców modeli jednocześnie (porównania).

---


## Pulumi — Infrastructure-as-Code

URL: https://eiac.dev/katalog/pulumi
Repo: https://github.com/pulumi/pulumi
Licencja: Apache-2.0

Pulumi pozwala opisywać infrastrukturę w pełnoprawnych językach programowania — TypeScript, Python, Go, C# — zamiast w dedykowanym DSL. Dzięki temu masz pętle, funkcje, pakiety, testy jednostkowe i podpowiedzi IDE bezpośrednio przy definicji zasobów. Pod spodem korzysta z tego samego modelu deklaratywnego co inne narzędzia IaC.

## Kiedy używać

- Twój zespół woli język programowania i istniejące narzędzia (testy, lintery, pakiety) zamiast HCL.
- Potrzebujesz abstrakcji wyższego poziomu i logiki przy generowaniu zasobów.
- Chcesz współdzielić komponenty jako zwykłe biblioteki.

## Przykład użycia

```ts
import * as aws from "@pulumi/aws";

const bucket = new aws.s3.Bucket("assets", {
  tags: { project: "eiac" },
});

export const bucketName = bucket.id;
```

```bash
pulumi preview   # podgląd zmian
pulumi up        # wdrożenie
```

## Warto wiedzieć

- Stan trzymany w Pulumi Cloud lub własnym backendzie (S3/GCS/Azure Blob).
- Umożliwia testy jednostkowe i policy-as-code (CrossGuard).

---


## release-please — SDLC / Policy-as-Code

URL: https://eiac.dev/katalog/release-please
Repo: https://github.com/googleapis/release-please
Licencja: Apache-2.0

release-please automatyzuje wydania: na podstawie commitów w stylu Conventional Commits wylicza kolejną wersję (SemVer), generuje changelog i otwiera „release PR". Po jego scaleniu tworzy tag i release. Cały proces wydawniczy staje się powtarzalnym, sterowanym z repo krokiem — bez ręcznego pilnowania wersji i notatek.

## Kiedy używać

- Chcesz automatycznych wersji i changelogów z historii commitów.
- Stosujesz Conventional Commits i SemVer.
- Wolisz „release PR" do akceptacji zamiast ręcznych tagów.

## Przykład użycia

```text
feat: dodaj filtr katalogu      → bump minor (1.1.0 → 1.2.0)
fix: popraw link w stopce       → bump patch (1.2.0 → 1.2.1)
feat!: zmiana API              → bump major (1.x → 2.0.0)
```

release-please zbiera takie commity i otwiera PR z nową wersją + changelogiem.

## Warto wiedzieć

- Działa jako akcja CI; wpinasz w [Gitea](/katalog/gitea) Actions / inne CI.
- Spina się z konwencją commitów egzekwowaną np. w [MegaLinter](/katalog/megalinter).

---


## Scalr — Infrastructure-as-Code

URL: https://eiac.dev/katalog/scalr
Licencja: Proprietary

Scalr to komercyjna platforma TACOS zaprojektowana jako **drop-in zamiennik Terraform Cloud/Enterprise**: oferuje ten sam model remote-operations backend (zgodne CLI, API i model stanu), więc migracja bywa płynna. Wspiera [Terraform](/katalog/terraform) i [OpenTofu](/katalog/opentofu), GitOps, przepływy API-driven oraz no-code, z politykami na bazie [OPA](/katalog/open-policy-agent).

## Kiedy używać

- Migrujesz z Terraform Cloud i chcesz zachować ten sam CLI/API/model stanu.
- Wolisz rozliczenie zależne od liczby uruchomień, nie od współbieżności.
- Potrzebujesz hierarchii środowisk i polityk na wielu poziomach.

## Przykład użycia

```hcl
# backend zgodny z modelem zdalnym — minimalna zmiana przy migracji
terraform {
  cloud {
    hostname     = "scalr.io"
    organization = "eiac"
    workspaces { name = "sovereign-eu" }
  }
}
```

## Warto wiedzieć

- Rozliczenie per run (współbieżność i self-hostowani agenci nie są czynnikiem cennika); jest darmowy próg miesięcznych uruchomień.
- Alternatywy: [Spacelift](/katalog/spacelift), [env0](/katalog/env0) (FinOps), [OpenTaco](/katalog/digger) (open-source, self-hosted).
- Polityki utrzymuj jako [policy-as-code](/blog/policy-as-code-dla-zespolow).

---


## semantic-release — SDLC / Policy-as-Code

URL: https://eiac.dev/katalog/semantic-release
Repo: https://github.com/semantic-release/semantic-release
Licencja: MIT

semantic-release w pełni automatyzuje cykl wydawniczy: po merge do gałęzi wydawniczej analizuje commity (Conventional Commits), ustala kolejną wersję wg SemVer, generuje changelog i publikuje wydanie — przez bogaty ekosystem wtyczek (npm, GitLab/GitHub Releases, obrazy i inne). W odróżnieniu od modelu „release PR" działa w trybie *publish-on-merge*: nie ma ręcznego kroku zatwierdzenia wersji, więc droga od merge do wydania jest najkrótsza.

## Kiedy używać

- Chcesz pełnej automatyzacji wydań bez ręcznego podbijania wersji.
- Publikujesz pakiety/artefakty często i chcesz krótkiej drogi merge → release.
- Potrzebujesz kanałów wydawniczych (stable / next / beta / maintenance).

## Przykład użycia

```json
// .releaserc.json — kanały + wtyczki
{
  "branches": ["main", { "name": "beta", "prerelease": true }],
  "plugins": [
    "@semantic-release/commit-analyzer",
    "@semantic-release/release-notes-generator",
    "@semantic-release/changelog",
    "@semantic-release/gitlab",
    "@semantic-release/git"
  ]
}
```

```bash
npx semantic-release      # zwykle uruchamiane w CI po merge do main
```

## Warto wiedzieć

- Kanały: `main` → stabilne, `next`/`beta` → pre-release, `1.x` → wydania utrzymaniowe.
- Model „publish-on-merge" — kontrolę przenosisz na etap PR z kodem; jeśli wolisz jawną „bramkę wersji", rozważ [release-please](/katalog/release-please).
- Działa na [GitLab](/katalog/gitlab), [Gitea](/katalog/gitea) i innych platformach przez wtyczki.

---


## Semaphore — Infrastructure-as-Code

URL: https://eiac.dev/katalog/semaphore
Repo: https://github.com/semaphoreui/semaphore
Licencja: MIT

Semaphore to nowoczesny interfejs i API do uruchamiania narzędzi DevOps: [Ansible](/katalog/ansible), [Terraform](/katalog/terraform)/[OpenTofu](/katalog/opentofu)/[Terragrunt](/katalog/terragrunt), PowerShell i innych. Zamiast odpalać playbooki i plany z konsoli, masz centralne miejsce z harmonogramami, uprawnieniami, sekretami i historią uruchomień — przy zachowaniu kodu (repozytoria) jako źródła prawdy.

## Kiedy używać

- Chcesz kontrolowanego uruchamiania IaC/Ansible przez zespół (kto, co, kiedy).
- Potrzebujesz harmonogramów, uprawnień i audytu uruchomień.
- Wolisz UI/API zamiast luźnych skryptów, ale trzymasz kod w repo.

## Przykład użycia

```text
1. Podłącz repozytorium (np. z Gitei) z playbookami/modułami.
2. Zdefiniuj „Template" (Ansible playbook lub Terraform plan/apply).
3. Uruchom ręcznie lub w harmonogramie; przeglądaj log i historię.
```

## Warto wiedzieć

- Kod (playbooki/moduły) pozostaje w Gicie; Semaphore to warstwa uruchomieniowa.
- Do orkiestracji IaC w samym CI rozważ też [Digger](/katalog/digger).

---


## SOPS — Security-as-Code

URL: https://eiac.dev/katalog/sops
Repo: https://github.com/getsops/sops
Licencja: MPL-2.0

SOPS szyfruje wartości w plikach YAML/JSON/ENV (zostawiając klucze czytelnymi), używając kluczy z KMS (AWS/GCP/Azure), [age](/katalog/age) lub PGP. Dzięki temu sekrety możesz bezpiecznie trzymać w repozytorium Git — zaszyfrowane — i odszyfrowywać dopiero przy wdrożeniu. To kanoniczne podejście „secrets-as-code" w świecie GitOps.

## Kiedy używać

- Chcesz wersjonować sekrety w Git bez ujawniania wartości.
- Pracujesz w GitOps ([Flux](/katalog/flux)/[Argo CD](/katalog/argo-cd)) i potrzebujesz szyfrowanych manifestów.
- Wolisz proste szyfrowanie plików zamiast serwera sekretów.

## Przykład użycia

```bash
# szyfrowanie kluczem age
sops --encrypt --age $AGE_PUBKEY secrets.yaml > secrets.enc.yaml
sops --decrypt secrets.enc.yaml
```

```yaml
# secrets.enc.yaml — klucze jawne, wartości zaszyfrowane
db_password: ENC[AES256_GCM,data:…,tag:…]
```

## Warto wiedzieć

- Najczęściej używany z [age](/katalog/age) (proste klucze) albo KMS chmury.
- Uzupełnia, a nie zastępuje, serwery sekretów jak [Vault](/katalog/vault)/[OpenBao](/katalog/openbao).

---


## Spacelift — Infrastructure-as-Code

URL: https://eiac.dev/katalog/spacelift
Licencja: Proprietary

Spacelift to komercyjna platforma z kategorii **TACOS** (Terraform/OpenTofu Automation and Collaboration Software) — warstwa zarządzania nad samym silnikiem IaC. Spina w spójny przepływ GitOps wiele narzędzi naraz ([Terraform](/katalog/terraform), [OpenTofu](/katalog/opentofu), [Pulumi](/katalog/pulumi), CloudFormation, [Kubernetes](/katalog/kubernetes), [Ansible](/katalog/ansible)), dokładając to, czego nie daje zwykłe CI: blokady stanu, prywatne rejestry, granularny RBAC, wykrywanie i naprawę driftu oraz polityki jako kod.

## Kiedy używać

- Masz wiele zespołów i stacków IaC, które rozjeżdżają się w sposobach pracy.
- Potrzebujesz drift detection z automatyczną naprawą i twardego RBAC.
- Chcesz egzekwować polityki (na bazie [OPA](/katalog/open-policy-agent)) na etapie planu i przed `apply`.

## Przykład użycia

```yaml
# .spacelift/config.yml — polityki i hooki wpięte w stack
version: "1"
stack:
  before_apply:
    - conftest test plan.json
  policies:
    - plan-must-be-encrypted
```

## Warto wiedzieć

- Model rozliczeń oparty o liczbę workerów (= maksymalna współbieżność); płatny tier startuje wysoko — to wybór dla większych organizacji.
- Otwartą, „w Twoim CI" alternatywą jest [OpenTaco](/katalog/digger); lekki orkiestrator open-source to [Terramate](/katalog/terramate).
- Polityki pisze się jako [policy-as-code](/blog/policy-as-code-dla-zespolow), spójnie z resztą platformy.

---


## SST — App-as-Code

URL: https://eiac.dev/katalog/sst
Repo: https://github.com/sst/sst
Licencja: MIT

SST to framework do budowy i wdrażania aplikacji na AWS, w którym infrastrukturę i kod aplikacji opisujesz razem w TypeScript. Wersja v3 stoi na silniku Pulumi/Terraform, a tryb `dev` daje lokalną pętlę developerską z podglądem na żywo zasobów w chmurze. Zamiast ręcznie składać dziesiątki usług, korzystasz z gotowych, wysokopoziomowych komponentów.

## Kiedy używać

- Budujesz aplikacje serverless/full-stack na AWS i chcesz mieć infrastrukturę w tym samym repo.
- Zależy Ci na szybkim DX (live dev, typowanie zasobów) bez ręcznego klikania w konsoli.
- Wdrażasz frontend (Next/Astro/itd.) razem z backendem i bazą.

## Przykład użycia

```ts
// sst.config.ts
export default $config({
  app: () => ({ name: "eiac", home: "aws" }),
  async run() {
    const bucket = new sst.aws.Bucket("Assets");
    new sst.aws.Astro("Web", { link: [bucket] });
  },
});
```

```bash
npx sst dev      # lokalna pętla developerska
npx sst deploy   # wdrożenie na AWS
```

## Warto wiedzieć

- `link` automatycznie przekazuje uprawnienia i zmienne do aplikacji — mniej ręcznej konfiguracji IAM.
- Alternatywa o silniejszej konwencji: [Encore](/katalog/encore).

---


## Storybook — Design-as-Code

URL: https://eiac.dev/katalog/storybook
Repo: https://github.com/storybookjs/storybook
Licencja: MIT

Storybook to środowisko do budowania i dokumentowania komponentów UI w izolacji od aplikacji. Każdy stan komponentu opisujesz jako „story" — żywą, interaktywną dokumentację, która jednocześnie służy jako baza testów wizualnych i dostępności. To pomost między design systemem a kodem: komponenty z tokenów żyją, są przeglądalne i testowalne.

## Kiedy używać

- Budujesz bibliotekę komponentów / design system i chcesz ją dokumentować na żywo.
- Potrzebujesz testów wizualnych, interakcji i dostępności komponentów.
- Chcesz przeglądać warianty komponentu bez uruchamiania całej aplikacji.

## Przykład użycia

```ts
// Button.stories.ts
import type { Meta, StoryObj } from '@storybook/your-framework';
import { Button } from './Button';

const meta: Meta<typeof Button> = { component: Button };
export default meta;

export const Primary: StoryObj<typeof Button> = {
  args: { variant: 'primary', label: 'Zapisz się' },
};
```

```bash
npm run storybook   # lokalny warsztat komponentów
```

## Warto wiedzieć

- Wspiera większość frameworków (React, Vue, Svelte, web components).
- Komponenty zasilane tokenami ze [Style Dictionary](/katalog/style-dictionary) prezentujesz tu jako żywą dokumentację.

---


## Style Dictionary — Design-as-Code

URL: https://eiac.dev/katalog/style-dictionary
Repo: https://github.com/amzn/style-dictionary
Licencja: Apache-2.0

Style Dictionary to build system dla design tokenów. Definiujesz wartości (kolory, typografię, odstępy) raz, w plikach JSON/JSON5, a narzędzie generuje z nich pliki dla wielu platform: CSS variables, SCSS, stałe iOS/Android, JS/TS i inne. To fundament „design-as-code" — jedno źródło prawdy zasila kod, stronę i materiały marki.

## Kiedy używać

- Utrzymujesz spójny system kolorów/typografii w wielu produktach i platformach.
- Chcesz, by zmiana tokenu propagowała się automatycznie do całego kodu.
- Budujesz własny design system (np. dla eiac.dev).

## Przykład użycia

```json
// tokens/color.json
{ "color": { "rust": { "value": "#A8482A" } } }
```

```js
// config.js — eksport do CSS variables
export default {
  source: ["tokens/**/*.json"],
  platforms: {
    css: { transformGroup: "css", files: [{ destination: "tokens.css", format: "css/variables" }] }
  }
};
```

```bash
npx style-dictionary build   # → tokens.css z :root { --color-rust: #A8482A; }
```

## Warto wiedzieć

- Wspiera własne transformy i formaty — dopasujesz output do swojego stacku.
- Świetnie współgra z narzędziami projektowymi eksportującymi tokeny (np. [Penpot](/katalog/penpot)).

---


## Task — SDLC / Policy-as-Code

URL: https://eiac.dev/katalog/task
Repo: https://github.com/go-task/task
Licencja: MIT

Task to szybki, wieloplatformowy task runner — nowoczesna alternatywa dla Make. Zadania (build, test, deploy, lint) definiujesz deklaratywnie w `Taskfile.yml`, z zależnościami, zmiennymi i inteligentnym pomijaniem zadań, gdy nic się nie zmieniło. To prosty sposób, by „polecenia projektu" stały się wersjonowanym kodem, identycznym lokalnie i w CI.

## Kiedy używać

- Chcesz czytelnych, wieloplatformowych komend projektu w jednym pliku.
- Zastępujesz rozjeżdżające się skrypty `Makefile`/bash.
- Współdzielisz te same zadania między dev i CI.

## Przykład użycia

```yaml
# Taskfile.yml
version: '3'
tasks:
  build:
    cmds: [npm ci, npm run build]
    sources: ["src/**/*"]
  deploy:
    deps: [build]
    cmds: [npx wrangler pages deploy dist --project-name=eiac]
```

```bash
task build
task deploy
```

## Warto wiedzieć

- `sources` pozwala pomijać zadania, gdy pliki się nie zmieniły.
- Świetnie współgra z CI ([Woodpecker](/katalog/woodpecker)) i [Dagger](/katalog/dagger).

---


## Teller — Security-as-Code

URL: https://eiac.dev/katalog/teller
Repo: https://github.com/tellerops/teller
Licencja: Apache-2.0

Teller to narzędzie CLI do pracy z sekretami z wielu źródeł jednocześnie (Vault, chmurowe menedżery sekretów, pliki) bez opuszczania terminala. Konfigurację mapowania sekretów opisujesz deklaratywnie w YAML, a Teller wstrzykuje je do procesu, skanuje repo pod kątem wycieków i synchronizuje między backendami. Sekrety pozostają poza repo, a ich źródło jest jawnie zdefiniowane jako kod.

## Kiedy używać

- Łączysz sekrety z wielu providerów w jednym, spójnym widoku.
- Chcesz wstrzykiwać sekrety do procesów lokalnie i w CI.
- Potrzebujesz wykrywania wycieków i synchronizacji między backendami.

## Przykład użycia

```yaml
# .teller.yml
providers:
  vault:
    kind: hashicorp_vault
    maps:
      - id: db
        path: secret/eiac/db
```

```bash
teller run -- npm start     # wstrzyknięcie sekretów do procesu
teller scan                 # wykrywanie wycieków w repo
```

## Warto wiedzieć

- Warstwa „spinająca" nad backendami jak [Vault](/katalog/vault)/[OpenBao](/katalog/openbao) i [Infisical](/katalog/infisical).
- Mapowania trzymaj w repo; same sekrety pozostają w backendach.

---


## Terraform — Infrastructure-as-Code

URL: https://eiac.dev/katalog/terraform
Repo: https://github.com/hashicorp/terraform
Licencja: BUSL-1.1

Terraform to standard branżowy dla infrastruktury jako kod. Opisujesz docelowy stan zasobów (sieci, maszyny, bazy, uprawnienia) w deklaratywnym języku HCL, a Terraform wylicza różnicę między stanem zapisanym a rzeczywistym i wykonuje tylko potrzebne zmiany. Dzięki setkom providerów obejmuje praktycznie każdą chmurę i usługę SaaS z jednego, spójnego workflow.

## Kiedy używać

- Zarządzasz infrastrukturą w wielu chmurach lub usługach i chcesz jednego, deklaratywnego narzędzia.
- Zależy Ci na podglądzie zmian (`plan`) przed ich wprowadzeniem i na powtarzalnych środowiskach.
- Budujesz reużywalne moduły współdzielone między zespołami.

## Przykład użycia

```hcl
terraform {
  required_providers {
    aws = { source = "hashicorp/aws", version = "~> 5.0" }
  }
}

resource "aws_s3_bucket" "assets" {
  bucket = "eiac-assets"
  tags   = { project = "eiac" }
}
```

```bash
terraform init      # pobranie providerów
terraform plan      # podgląd zmian
terraform apply     # wprowadzenie zmian
```

`plan` pokazuje dokładnie, co zostanie utworzone/zmienione/usunięte, zanim cokolwiek dotknie infrastruktury.

## Warto wiedzieć

- Stan trzymaj zdalnie (np. backend S3 + blokada), nigdy w repo.
- Po zmianie licencji na BUSL część społeczności przeszła na [OpenTofu](/katalog/opentofu) (fork MPL-2.0).
- Strukturyzuj kod w moduły i środowiska (workspaces lub osobne katalogi).

---


## Terragrunt — Infrastructure-as-Code

URL: https://eiac.dev/katalog/terragrunt
Repo: https://github.com/gruntwork-io/terragrunt
Licencja: MIT

Terragrunt to cienka nakładka na Terraform i [OpenTofu](/katalog/opentofu), która rozwiązuje problemy skali: powtarzalną konfigurację backendu, zależności między modułami i zarządzanie wieloma środowiskami bez kopiowania kodu. Dzięki niej trzymasz infrastrukturę „DRY" — wspólne ustawienia definiujesz raz i dziedziczysz w katalogach środowisk.

## Kiedy używać

- Masz wiele środowisk (dev/stage/prod) i nie chcesz duplikować kodu Terraform.
- Potrzebujesz zależności między modułami i spójnej konfiguracji backendu.
- Chcesz uruchamiać zmiany w wielu modułach jednym poleceniem.

## Przykład użycia

```hcl
# terragrunt.hcl — w katalogu środowiska
include "root" { path = find_in_parent_folders() }

terraform {
  source = "git::https://git.eiac.dev/eiac/modules.git//vpc?ref=v1.2.0"
}

inputs = { cidr = "10.0.0.0/16" }
```

```bash
terragrunt run-all plan    # plan dla wszystkich modułów
terragrunt run-all apply
```

## Warto wiedzieć

- Działa z Terraform i OpenTofu; konfigurację backendu generuje automatycznie.
- Dobrze łączy się z wersjonowanymi modułami trzymanymi w Gitei.

---


## Terramate — Infrastructure-as-Code

URL: https://eiac.dev/katalog/terramate
Repo: https://github.com/terramate-io/terramate
Licencja: MPL-2.0

Terramate CLI to **open-source** (licencja [MPL 2.0](https://www.mozilla.org/en-US/MPL/2.0/)) silnik orkiestracji i generowania kodu, który pozwala skalować IaC: [Terraform](/katalog/terraform), [OpenTofu](/katalog/opentofu), [Terragrunt](/katalog/terragrunt) i [Kubernetes](/katalog/kubernetes). Dzieli wielki, monolityczny stan („Terralith") na mniejsze jednostki — **stacki** — i uruchamia je równolegle, deployując tylko te, w których wykryto zmianę (change detection oparte o Git).

## Kiedy używać

- Twój stan IaC urósł w monolit i chcesz go podzielić na niezależne stacki.
- Zależy Ci na uruchamianiu tylko zmienionych stacków (szybkie CI, mniejszy promień rażenia).
- Chcesz ograniczyć duplikację przez generowanie konfiguracji backendu/providerów.

## Przykład użycia

```hcl
# stack.tm.hcl — definicja stacku Terramate
stack {
  name        = "sovereign-eu-web"
  description = "Web w suwerennej lokalizacji EU"
}
```

```bash
# uruchom tylko stacki ze zmianami względem main
terramate run --changed -- tofu apply
```

## Warto wiedzieć

- Wpina się w istniejący projekt jedną komendą, bez ruszania obecnej konfiguracji.
- Firma oferuje też Terramate Cloud (komercyjnie: observability, drift detection, polityki).
- Lekka, otwarta alternatywa wobec platform jak [Spacelift](/katalog/spacelift)/[env0](/katalog/env0); do orkiestracji w samym CI zob. [OpenTaco](/katalog/digger).

---


## Terrascan — Security-as-Code

URL: https://eiac.dev/katalog/terrascan
Repo: https://github.com/tenable/terrascan
Licencja: Apache-2.0

Terrascan wykrywa naruszenia bezpieczeństwa i zgodności w infrastrukturze jako kod (Terraform, Kubernetes, Helm, Dockerfile) zanim cokolwiek zostanie zaprovisionowane. Reguły opiera o politykę pisaną w Rego (jak [Open Policy Agent](/katalog/open-policy-agent)), więc własne standardy zapiszesz deklaratywnie i wymusisz w pipeline.

## Kiedy używać

- Skanujesz IaC ([Terraform](/katalog/terraform)/[Kubernetes](/katalog/kubernetes)) pod kątem zgodności i bezpieczeństwa.
- Chcesz polityk w Rego, spójnych z ekosystemem OPA.
- Bramkujesz PR-y i plan przed `apply`.

## Przykład użycia

```bash
terrascan scan -i terraform -d .
terrascan scan -i k8s -d ./manifests
```

```yaml
# Gitea Actions — fail przy naruszeniach
- run: terrascan scan -d infra --verbose
```

## Warto wiedzieć

- Pokrywa się funkcjonalnie z [Checkov](/katalog/checkov) — wybór zależy od preferencji (Rego vs Python/YAML).
- Polityki trzymaj w repo i wersjonuj jak kod.

---


## Toast — SDLC / Policy-as-Code

URL: https://eiac.dev/katalog/toast
Repo: https://github.com/stepchowfun/toast
Licencja: MIT

Toast pozwala definiować zadania dev i CI w pliku YAML, gdzie każdy krok wykonuje się w kontenerze. Dzięki temu te same, powtarzalne środowiska działają identycznie lokalnie i na CI — z cache'owaniem i zależnościami między zadaniami. To sposób, by „jak budujemy i testujemy" stało się przenośnym kodem, niezależnym od konkretnego dostawcy CI.

## Kiedy używać

- Chcesz powtarzalnych, kontenerowych zadań dev/CI niezwiązanych z jednym CI.
- Zależy Ci na identycznym środowisku lokalnie i w pipeline.
- Wolisz prosty plik YAML zamiast skryptów per-CI.

## Przykład użycia

```yaml
# toast.yml
tasks:
  build:
    image: node:20
    command: npm ci && npm run build
  test:
    dependencies: [build]
    command: npm test
```

```bash
toast build    # uruchomienie w kontenerze
```

## Warto wiedzieć

- Pokrewne ideowo z [Dagger](/katalog/dagger) (przenośne, kontenerowe pipeline'y).
- Dobrze sprawdza się jako wspólny „runner" zadań dla dev i CI.

---


## Tokens Studio — Design-as-Code

URL: https://eiac.dev/katalog/tokens-studio
Repo: https://github.com/tokens-studio/figma-plugin
Licencja: MIT

Tokens Studio pozwala tworzyć i utrzymywać design tokeny bezpośrednio w narzędziu projektowym, a następnie synchronizować je z repozytorium Git jako pliki JSON. Dzięki temu projektant i kod pracują na jednym źródle prawdy: zmiana tokenu w projekcie trafia do repo, a stamtąd — np. przez [Style Dictionary](/katalog/style-dictionary) — do CSS i kodu.

## Kiedy używać

- Chcesz, by tokeny powstawały po stronie projektu i automatycznie wracały do kodu.
- Utrzymujesz wiele motywów/marek i potrzebujesz aliasów oraz semantycznych warstw tokenów.
- Domykasz pętlę „design ↔ code" bez ręcznego przepisywania wartości.

## Przykład użycia

```json
// tokens.json synchronizowane z repo
{
  "color": {
    "rust":  { "value": "#A8482A", "type": "color" },
    "link":  { "value": "{color.rust}", "type": "color" }
  }
}
```

```bash
# w repo: tokens.json → Style Dictionary → tokens.css
npx style-dictionary build
```

## Warto wiedzieć

- Aliasy (`{color.rust}`) pozwalają budować semantyczne warstwy tokenów.
- Naturalnie spina się ze [Style Dictionary](/katalog/style-dictionary) i [Penpot](/katalog/penpot).

---


## Trivy — Security-as-Code

URL: https://eiac.dev/katalog/trivy
Repo: https://github.com/aquasecurity/trivy
Licencja: Apache-2.0

Trivy to wszechstronny skaner bezpieczeństwa: wykrywa znane podatności (CVE) w obrazach kontenerów i zależnościach, błędy konfiguracji w plikach IaC (Terraform, Kubernetes, Dockerfile), wycieki sekretów oraz generuje SBOM. Jest szybki, działa offline z lokalną bazą i łatwo wpina się w pipeline — bezpieczeństwo staje się bramką w CI, nie ręcznym audytem.

## Kiedy używać

- Skanujesz obrazy i zależności pod kątem CVE przed wdrożeniem.
- Sprawdzasz manifesty IaC/Kubernetes pod kątem złych konfiguracji.
- Chcesz jednego narzędzia do CVE, sekretów, IaC i SBOM.

## Przykład użycia

```bash
trivy image ghcr.io/eiac/web:1.0.0      # podatności w obrazie
trivy config ./infra                     # błędy konfiguracji IaC
trivy fs --scanners secret .             # wycieki sekretów
```

```yaml
# krok w pipeline — fail przy krytycznych CVE
- run: trivy image --exit-code 1 --severity CRITICAL ghcr.io/eiac/web:1.0.0
```

## Warto wiedzieć

- Dobrze łączy się z politykami [Open Policy Agent](/katalog/open-policy-agent) (Conftest/Rego).
- `--exit-code` zamienia skan w twardą bramkę CI.

---


## TruffleHog — Security-as-Code

URL: https://eiac.dev/katalog/trufflehog
Repo: https://github.com/trufflesecurity/trufflehog
Licencja: AGPL-3.0

TruffleHog skanuje repozytoria, historię Git, obrazy, logi i wiele innych źródeł w poszukiwaniu sekretów — a co kluczowe, potrafi je **zweryfikować**, sprawdzając, czy znaleziony klucz nadal działa. To ogranicza szum fałszywych alarmów i pozwala priorytetyzować realne wycieki. Wpina się w pre-commit i CI jako bramka.

## Kiedy używać

- Chcesz wykrywać sekrety z weryfikacją „czy ten klucz żyje".
- Skanujesz nie tylko repo, ale też obrazy, S3, logi.
- Budujesz bramkę w CI i hook pre-commit.

## Przykład użycia

```bash
trufflehog git https://git.eiac.dev/eiac/web --only-verified
trufflehog filesystem ./ --only-verified
```

```yaml
# Gitea Actions — fail przy zweryfikowanym sekrecie
- run: trufflehog git file://. --only-verified --fail
```

## Warto wiedzieć

- Komplementarny do [Gitleaks](/katalog/gitleaks): TruffleHog weryfikuje, Gitleaks jest lekki i regułowy — wielu używa obu.
- `--only-verified` mocno redukuje fałszywe alarmy.

---


## Vault — Security-as-Code

URL: https://eiac.dev/katalog/vault
Repo: https://github.com/hashicorp/vault
Licencja: BUSL-1.1

Vault centralizuje sekrety (klucze API, hasła, certyfikaty) i udostępnia je aplikacjom przez API, zamiast trzymać je w plikach czy zmiennych środowiskowych. Potrafi generować sekrety dynamicznie i krótkożyciowo (np. czasowe dane dostępowe do bazy), szyfrować dane „as a service" oraz egzekwować polityki dostępu. Konfigurację — politykę, silniki sekretów, role — opisujesz deklaratywnie, więc bezpieczeństwo też staje się kodem.

## Kiedy używać

- Chcesz wyeliminować sekrety z repo i plików konfiguracyjnych.
- Potrzebujesz krótkożyciowych, automatycznie rotowanych poświadczeń.
- Egzekwujesz dostęp do sekretów politykami (least privilege).

## Przykład użycia

```bash
vault kv put secret/eiac/db password="s3cret"
vault kv get -field=password secret/eiac/db
```

```hcl
# polityka dostępu jako kod
path "secret/data/eiac/*" {
  capabilities = ["read"]
}
```

Aplikacja uwierzytelnia się (np. tokenem K8s) i pobiera sekret w runtime — nic nie ląduje w repo.

## Warto wiedzieć

- Provisioning Vaulta zautomatyzujesz [Terraform](/katalog/terraform)/[OpenTofu](/katalog/opentofu) (provider Vault).
- Dynamiczne sekrety mocno ograniczają „blast radius" wycieku.
- Otwarta alternatywa po zmianie licencji na BUSL: [OpenBao](/katalog/openbao) (fork MPL-2.0).

---


## Velero — App-as-Code

URL: https://eiac.dev/katalog/velero
Repo: https://github.com/velero-io/velero
Licencja: Apache-2.0

Velero wykonuje backup i przywracanie zasobów Kubernetes oraz trwałych wolumenów, a także migruje aplikacje między klastrami. Harmonogramy i zakres backupów definiujesz deklaratywnie (CRD), więc disaster recovery staje się powtarzalnym, wersjonowanym procesem — a nie ręczną akcją „na już". Backupy lądują w obiektowym storage (S3-kompatybilnym).

## Kiedy używać

- Potrzebujesz backupu/DR aplikacji i wolumenów w [Kubernetes](/katalog/kubernetes).
- Migrujesz workloady między klastrami/chmurami.
- Chcesz harmonogramów backupu opisanych deklaratywnie.

## Przykład użycia

```bash
velero backup create eiac-daily --include-namespaces web
velero schedule create daily --schedule "0 3 * * *" --include-namespaces web
velero restore create --from-backup eiac-daily
```

## Warto wiedzieć

- Backup wolumenów uzupełnia storage z replikacją ([Longhorn](/katalog/longhorn)).
- Definicje backupów/harmonogramów trzymaj w repo (GitOps).

---


## Warpgate — Security-as-Code

URL: https://eiac.dev/katalog/warpgate
Repo: https://github.com/warp-tech/warpgate
Licencja: Apache-2.0

Warpgate to w pełni transparentny bastion (PAM — Privileged Access Management) dla SSH, HTTPS, MySQL, Postgres i Kubernetes, napisany w bezpiecznym Rust. Uwierzytelnia użytkownika, a potem przezroczyście przekazuje połączenie do serwera docelowego, robiąc po drodze nagranie sesji do audytu. Kluczowa różnica wobec zwykłego jump-hosta: **precyzyjne przypisanie 1:1 użytkownik↔usługa** zamiast dostępu do całej sieci — i to bez instalowania klienta po stronie użytkownika.

## Kiedy używać

- Chcesz kontrolowanego, audytowalnego dostępu do infrastruktury (SSH/bazy/K8s) z jednego miejsca.
- Potrzebujesz SSO (OIDC), 2FA i RBAC „z pudełka", bez doklejania wtyczek PAM.
- Zależy Ci na self-hostingu — jeden binarny plik lub obraz Docker na własnym sprzęcie, dane po Twojej stronie.

## Przykład użycia

```bash
# specjalnie formatowana nazwa użytkownika wybiera cel przez bastion
$ ssh c.wilde:staging-env@warpgate.acme.inc

 Warpgate  Selected target: staging-env
 ✓ Warpgate connected
 root@staging-env ~ $
```

Dostępem (użytkownicy, cele, kto co widzi) zarządzasz deklaratywnie, a każda sesja zostawia nagranie i log do audytu.

## Warto wiedzieć

- Pełni rolę bramy tożsamości i dostępu w [Security Plane](/blog/security-plane-sekrety-tozsamosc-policy); SSO domykają brokerzy OIDC jak [Dex](/katalog/dex)/[Ory Hydra](/katalog/ory-hydra).
- Sekrety i poświadczenia trzymaj w [Vault](/katalog/vault)/[OpenBao](/katalog/openbao); polityki dostępu opisuj jako [policy-as-code](/blog/policy-as-code-dla-zespolow).
- 100% open-source (Apache-2.0), finansowany kontraktami wsparcia — bez płatnych planów i modelu SaaS.

---


## Watchtower — SDLC / Policy-as-Code

URL: https://eiac.dev/katalog/watchtower
Repo: https://github.com/containrrr/watchtower
Licencja: Apache-2.0

Watchtower obserwuje uruchomione kontenery i automatycznie aktualizuje je, gdy w rejestrze pojawi się nowy obraz dla używanego tagu — pobiera nową wersję i wdraża ją z zachowaniem dotychczasowej konfiguracji. To prosty sposób na ciągłe dostarczanie dla środowisk opartych o Docker/Compose, bez pełnego klastra Kubernetes.

## Kiedy używać

- Hostujesz usługi w Dockerze/Compose i chcesz automatycznych aktualizacji obrazów.
- Nie potrzebujesz pełnego GitOps na Kubernetes, a chcesz „auto-update".
- Utrzymujesz mały serwer/homelab z wieloma kontenerami.

## Przykład użycia

```bash
docker run -d --name watchtower \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower --interval 3600
```

Watchtower co godzinę sprawdza rejestr i aktualizuje kontenery z nowym obrazem.

## Warto wiedzieć

- Dla Kubernetes zamiast tego używaj GitOps ([Argo CD](/katalog/argo-cd)/[Flux](/katalog/flux)).
- Dobrze współgra z własnym rejestrem ([Harbor](/katalog/harbor)).

---


## Winglang (Wing) — App-as-Code

URL: https://eiac.dev/katalog/winglang
Repo: https://github.com/winglang/wing
Licencja: MIT

Wing to **zorientowany na chmurę język programowania**, którego teza jest mocna: istniejące języki nie wystarczają, by dobrze opisać aplikacje chmurowe, bo mieszają dwie fazy życia kodu. Wing rozdziela je jawnie: **preflight** to kod wykonywany raz, przy kompilacji, który generuje konfigurację infrastruktury (kompiluje się do Terraform lub CDK), a **inflight** to kod aplikacji działający w runtime. Usługi chmurowe są tu obywatelami pierwszej kategorii, a kompilator pilnuje granicy między fazami. Dla zespołów, które nie chcą uczyć się nowego języka, Wing oferuje też SDK dla TypeScript.

## Kiedy używać

- Chcesz opisać aplikację i jej infrastrukturę w **jednym, spójnym modelu**, bez rozjeżdżania się kodu i IaC.
- Zależy Ci na jawnym rozróżnieniu „co dzieje się przy wdrożeniu" vs „co w runtime" — z kontrolą kompilatora.
- Celujesz w przenośność między chmurami (Wing kompiluje do znanych silników, nie zamyka Cię w jednej platformie).

## Przykład użycia

```js
// preflight: definicja infrastruktury (bucket)
bring cloud;
let store = new cloud.Bucket();

// inflight: logika runtime reagująca na zdarzenie
let handler = inflight (msg: str) => {
  store.put("ostatni.txt", msg);
};
```

## Warto wiedzieć

- Kompiluje się do [Terraform](/katalog/terraform)/[OpenTofu](/katalog/opentofu) lub CDK — infrastruktura zostaje w otwartych, znanych formatach.
- To inny punkt na osi „infrastructure-from-code" niż [SST](/katalog/sst) (framework IaC) czy [Encore](/katalog/encore) (infra wywodzona z kodu); porównanie podejść: [IaC w 2026](/blog/iac-2026-przeglad).
- Nowy język to koszt wejścia — SDK dla TypeScript łagodzi go, ale warto policzyć adopcję zespołu.

---


## Woodpecker CI — SDLC / Policy-as-Code

URL: https://eiac.dev/katalog/woodpecker
Repo: https://github.com/woodpecker-ci/woodpecker
Licencja: Apache-2.0

Woodpecker to lekki, samodzielnie hostowany silnik CI/CD. Pipeline'y opisujesz deklaratywnie w pliku YAML w repo, a każdy krok uruchamia się w kontenerze. Jest prosty w utrzymaniu i dobrze integruje się z serwerami Git (w tym z naszą Gitą), więc stanowi naturalną, otwartą alternatywę dla zamkniętych usług CI.

## Kiedy używać

- Chcesz self-hostowanego CI/CD blisko repozytoriów (np. Gitea).
- Wolisz prosty, kontenerowy model pipeline'ów jako kod.
- Zależy Ci na lekkości i przejrzystości zamiast rozbudowanej platformy.

## Przykład użycia

```yaml
# .woodpecker.yml
steps:
  build:
    image: node:20
    commands:
      - npm ci
      - npm run build
  deploy:
    image: node:20
    commands: [npx wrangler pages deploy dist --project-name=eiac]
    when: { branch: main }
```

## Warto wiedzieć

- Składnia zbliżona do innych systemów pipeline-as-code; łatwa migracja.
- Do przenośnych kroków buildu łącz z [Dagger](/katalog/dagger).

---