Terraform vs Pulumi vs OpenTofu – porównanie narzędzi IaC w 2026

Sierpień 2023 przyniósł trzęsienie ziemi w świecie Infrastructure as Code. HashiCorp ogłosił zmianę licencji Terraform z open-source Mozilla Public License 2.0 na restrykcyjną Business Source License 1.1. W ciągu tygodni powstał OpenTofu – fork Terraform prowadzony przez Linux Foundation. Pulumi z kolei zyskał na popularności jako alternatywa pozwalająca pisać infrastrukturę w TypeScript, Python czy Go zamiast HCL.

Trzy lata później, w 2026 roku, masz do wyboru trzy dojrzałe narzędzia IaC – każde z inną filozofią, ekosystemem i modelem biznesowym. Jeśli jesteś Tech Lead albo Architektem planującym wybór narzędzia IaC (lub migrację z obecnego), ten artykuł to Twój kompas. Pokazuję szczegółowe porównanie, drzewo decyzyjne i realne scenariusze migracji. Bez korposłowia, z konkretnymi danymi i doświadczeniem z wdrożeń.

Na skróty

Czego dowiesz się z artykułu:

• Infrastructure as Code to nie tylko automatyzacja – to przede wszystkim collaboration, version control i auditability infrastruktury
• Terraform w 2026: BSL license ogranicza konkurencję, ale ekosystem pozostaje największy (4800+ providerów, 26M+ download/tydzień)
• OpenTofu: community-driven fork z 100% kompatybilnością wsteczną do Terraform 1.5.x, gwarancją open-source (Linux Foundation)
• Pulumi: infrastruktura w prawdziwych językach programowania (TypeScript, Python, Go, C#), ale mniejszy ekosystem providerów
• Kluczowe kryteria wyboru: licensing concerns, team skills (HCL vs general-purpose languages), cloud complexity, CI/CD integration
• Migracja Terraform → OpenTofu: drop-in replacement, 0 zmian w kodzie. Migracja do Pulumi: converter tools + refactoring
• Kompetencje IaC w zespole: version control, cloud platforms, security (secrets management, least privilege), testing/validation

Dla kogo ten artykuł:

• Tech Leads i DevOps Architects wybierający narzędzie IaC dla nowego projektu
• Zespoły używające Terraform i rozważające migrację do OpenTofu lub Pulumi
• Menedżerowie IT oceniający ryzyko związane z Terraform BSL license
• Platform Engineers budujący internal developer platforms z IaC jako core component

Czas czytania: 14 minut

Czym jest Infrastructure as Code i dlaczego jest kluczowe?

Infrastructure as Code (IaC) to podejście, w którym infrastrukturę (serwery, sieci, storage, load balancers, DNS) definiujesz w plikach kodu, a nie klikasz w konsoli cloud providera. Brzmi prosto, ale rewolucjonizuje sposób zarządzania infrastrukturą.

IaC to nie tylko automatyzacja – to przede wszystkim:

1. Version control– infrastruktura w Git. Widzisz historię zmian, możesz zrobić rollback, code review każdej zmiany w prod. 2. Collaboration– zespół pracuje na tej samej infrastrukturze bez konfliktów. Pull requesty zamiast “kto zmienił security group i nie powiedział?”. 3. Auditability– compliance teams pokochają Cię za to. Każda zmiana w infrastrukturze ma autor, timestamp, code review trail. 4. Repeatability– dev environment identyczny jak staging identyczny jak prod. “Works on my machine” przestaje być problemem w kontekście infrastruktury. 5. Disaster recovery– datacenter spłonęło? Uruchamiasz terraform apply w nowym regionie i masz identyczną infrastrukturę w 30 minut. Deklaratywne vs imperatywne IaC:

Narzędzia IaC dzielą się na dwa paradygmaty:

Deklaratywne (Terraform, OpenTofu, CloudFormation):

• Opisujesz desired state – “chcę 3 EC2 instances typu t3.large”
• Narzędzie samo wymyśla jak to osiągnąć (create/update/delete)
• Idempotentne – uruchomienie 10x tego samego kodu daje ten sam rezultat
• Łatwiejsze do reasoning – czytasz kod i wiesz, jaki będzie stan infrastruktury

Imperatywne (Pulumi w trybie imperatywnym, Ansible, bash scripts):

• Opisujesz kroki – “stwórz 3 EC2, potem attach security group, potem…”
• Większa kontrola, ale większe ryzyko – uruchomienie 2x może duplikować resources
• Trudniejsze do audytu – musisz “wykonać kod w głowie” żeby wiedzieć, co się stanie

Większość nowoczesnych narzędzi IaC (w tym wszystkie trzy z tego artykułu) to deklaratywne– i słusznie. Infrastruktura powinna być opisem stanu docelowego, nie skryptem wdrożeniowym. Dlaczego IaC jest kluczowe w 2026:

1. Multi-cloud i hybrid cloud – 78% enterprise działa w co najmniej 2 cloud providerach (Flexera State of Cloud 2026). Zarządzanie ręczne staje się niemożliwe.

2. Security i compliance – regulacje (GDPR, NIS2, SOC2) wymagają auditability. IaC daje pełną dokumentację zmian.

3. Developer velocity – platformy inżynierskie (Internal Developer Platforms) bazują na IaC. Devs mogą self-service provision environments w minuty, nie tygodnie.

4. Cost optimization – infrastruktura jako kod pozwala na automatyczne tear down środowisk dev/test poza godzinami pracy. Typowe oszczędności: 30-40% kosztów cloud.

5. Skill standardization – Junior może zrobić onboarding czytając IaC repository. Wiedza o infrastrukturze jest w kodzie, nie w głowach seniorów.

Terraform w 2026: HashiCorp, BSL i co dalej?

Terraform to de facto standard IaC od 2014 roku. W 2023 HashiCorp zmienił licencję na BSL (Business Source License 1.1), co zmieniło reguły gry. Gdzie jesteśmy trzy lata później?

Stan Terraform w liczbach (kwiecień 2026):

• 4800+ providerów w Terraform Registry – AWS, Azure, GCP, Kubernetes, Datadog, Cloudflare, GitHub… praktycznie każdy SaaS ma provider
• 26M+ downloads/tydzień Terraform CLI (dane HashiCorp)
• 98% kompatybilność wsteczna – kod z Terraform 0.12 (2019) często działa na 1.8 (2026) bez zmian
• Terraform Cloud: 50K+ organizacji, model SaaS do remote state i collaboration Co znaczy BSL license w praktyce:

Business Source License 1.1 od HashiCorp ma kluczowe ograniczenie:

“You may not provide the Licensed Work to third parties as a hosted or managed service, where the service provides users with access to any substantial set of the features or functionality of the Licensed Work.”

Co możesz robić:

• Używać Terraform w swojej firmie do zarządzania infrastrukturą – ✓
• Sprzedawać konsulting/wdrożenia Terraform klientom – ✓
• Budować internal developer platform na Terraform – ✓

Czego nie możesz robić:

• Stworzyć konkurencyjny produkt do Terraform Cloud (managed Terraform as a Service) – ✗
• Oferować Terraform jako część Twojego cloud platform offering (jeśli jesteś cloud provider) – ✗

Dla 95% firm BSL nie ma znaczenia – używają Terraform jako narzędzia wewnętrznego. Problem dotyka:

• Cloud providers budujących managed services
• Firmy tworzące Internal Developer Platforms sprzedawane zewnętrznie
• Open-source purists – BSL to nie jest open-source według OSI (Open Source Initiative) Korzyści z pozostania przy Terraform:

1. Biggest ecosystem – 4800 providerów to przepaść względem konkurencji. Niszowe SaaSy? Mają Terraform provider. OpenTofu? Jeszcze dorównuje. Pulumi? Ma konwertery, ale native providers są ograniczone.

2. Terraform Cloud – jeśli nie chcesz budować własnej infrastruktury CI/CD dla IaC, Terraform Cloud to solid choice. Remote state, policy as code (Sentinel), private registry.

3. Mature tooling – terraform fmt, validate, plan, graph – wszystko dopracowane. Debugging, error messages, dokumentacja – 12 lat developmentu widać.

4. Hiring– “Terraform experience” w CV ma 3x więcej kandydatów niż “Pulumi” (LinkedIn Talent Insights 2026). Łatwiej budować zespół. Ryzyka z Terraform w 2026:

5. Vendor lock-in – HashiCorp kontroluje development. Jeśli zdecydują podnieść ceny Terraform Cloud (a podnoszą – średnio 18% YoY), nie masz alternatywy bez migracji.

6. Licensing uncertainty – BSL ma “change date” (2027 dla wersji 1.6+), po którym kod staje się open-source (MPL 2.0). Ale HashiCorp może zmienić warunki w nowszych wersjach.

7. Community split– część community przeskoczyła do OpenTofu. Oznacza to mniej community contributions do Terraform, więcej energii w OpenTofu. Kiedy Terraform ma sens w 2026:

• Masz już deployment Terraform i nie chcesz migracji bez wyraźnego powodu
• Używasz niszowych providerów (sprawdź czy OpenTofu/Pulumi je mają)
• Terraform Cloud fit do Twojego workflow i budżetu
• BSL license nie jest problemem (nie budujesz konkurencyjnych produktów)

OpenTofu: open-source fork Terraform

OpenTofu to odpowiedź community na zmianę licencji Terraform. W sierpniu 2023, tydzień po ogłoszeniu BSL przez HashiCorp, grupa firm (Spacelift, env0, Scalr, Gruntwork) ogłosiła fork. W październiku 2023 OpenTofu został oficjalnym projektem Linux Foundation.

OpenTofu w liczbach (kwiecień 2026):

• 100% API-compatible z Terraform 1.5.x – drop-in replacement bez zmian w kodzie
• 4200+ providerów – większość Terraform providers działa z OpenTofu (OpenTofu Registry + Terraform Registry)
• Founding members: Spacelift, env0, Harness, Scalr, Gruntwork, Terramate, Digger + 25 innych firm
• 4M+ downloads/miesiąc (GitHub + package managers)
• MPL 2.0 license– gwarancja open-source na zawsze (Linux Foundation stewardship) Kluczowe różnice vs Terraform:

Aspekt	Terraform	OpenTofu
License	BSL 1.1 (commercial restrictions)	MPL 2.0 (open-source)
Governance	HashiCorp (single vendor)	Linux Foundation + community
Providerów	4800+ (Terraform Registry)	4200+ (kompatybilność z Terraform)
Compatibility	N/A	100% do Terraform 1.5.x
Cloud offering	Terraform Cloud (paid)	Współpraca z env0, Spacelift, Scalr
Development model	Closed (core team HashiCorp)	Open (community contributions)

OpenTofu od wersji 1.6 zaczął dodawać własne features – nie jest już tylko fork:

1. State encryption – natywne szyfrowanie state file (terraform.tfstate) bez external tools. Feature community chciało w Terraform od lat.

2. Improved testing framework – lepsze tofu test z support dla integration tests, mocking providerów.

3. Provider-defined functions – providerzy mogą definiować custom functions użyteczne w Terraform expressions (np. aws_account_id()).

4. Early evaluation– optymalizacje performance dla dużych state files (1000+ resources). Kompatybilność z Terraform providers:

OpenTofu używa tego samego Terraform Plugin Protocol (v6). Oznacza to:

• Terraform providers działają z OpenTofu out of the box
• Niektórzy vendorzy publikują do obu registries (Terraform Registry + OpenTofu Registry)
• Inni publikują tylko do Terraform Registry – ale OpenTofu może ich użyć (fallback)

Ryzyko: HashiCorp może w przyszłości wprowadzić breaking changes w Plugin Protocol, co wymusiłoby forking providerów przez OpenTofu. Na dziś (2026) nie ma takich sygnałów. Kiedy OpenTofu ma sens:

1. Licensing concerns – nie chcesz ryzyka związanego z BSL, wolisz gwarancję open-source

2. Community governance – wolisz model Linux Foundation niż single vendor control

3. New projects – zaczynasz od zera, nie ma lock-in na Terraform

4. Existing Terraform < 1.6– migracja to dosłownie zmiana binary (szczegóły w sekcji o migracji) Ryzyka z OpenTofu:

5. Młodsze narzędzie – 3 lata vs 12 lat Terraform. Niektóre edge cases mogą być buggy.

6. Mniejsze community (na razie) – Stack Overflow, tutoriale, kursy – większość jest o Terraform, nie OpenTofu. Choć kod jest kompatybilny, więc tutorials działają.

7. Brak managed SaaS od Linux Foundation – musisz użyć third-party (env0, Spacelift) lub self-host remote state.

Pulumi: IaC w ulubionym języku programowania

Pulumi to fundamentalnie inne podejście do IaC. Zamiast uczyć się DSL (HCL w przypadku Terraform/OpenTofu), piszesz infrastrukturę w TypeScript, Python, Go, C#, Java – prawdziwych językach programowania.

Pulumi w liczbach (kwiecień 2026):

• 150+ cloud/SaaS providers – mniej niż Terraform/OpenTofu, ale pokrywa 95% use cases
• 8 języków – TypeScript, JavaScript, Python, Go, C#, F#, Java, YAML
• Apache 2.0 license – open-source, bez ograniczeń BSL
• Pulumi Cloud – managed service do state management, secrets, CI/CD
• 2M+ downloads/miesiąc (npm + PyPI + Go modules) Fundamentalna różnica – real programming languages:

Terraform/OpenTofu:

variable "instance_count" {
  type    = number
  default = 3
}

resource "aws_instance" "app" {
  count         = var.instance_count
  ami           = "ami-12345678"
  instance_type = "t3.medium"

  tags = {
    Name = "app-${count.index}"
  }
}

Pulumi (TypeScript):

const instanceCount = 3;

const instances: aws.ec2.Instance[] = [];
for (let i = 0; i < instanceCount; i++) {
  instances.push(new aws.ec2.Instance(`app-${i}`, {
    ami: "ami-12345678",
    instanceType: "t3.medium",
    tags: { Name: `app-${i}` },
  }));
}

export const instanceIds = instances.map(i => i.id);

Co to daje:

1. Loops, conditionals, functions – pełna moc języka. W Terraform loopy przez count/for_each są ograniczone. W Pulumi używasz normalnych for, if, map, filter.

2. IDE support – autocomplete, refactoring, jump-to-definition. Terraform ma to przez Language Server Protocol, ale Pulumi ma to natywnie (bo to TypeScript/Python/Go).

3. Testing – unit testy infrastruktury w Jest (TypeScript) czy pytest (Python). Mock cloud resources, testuj logikę bez provisioning.

4. Package managers – npm, PyPI, Go modules. Reusable components jako packages, semver, dependency management.

5. Existing ecosystem– lodash, axios, crypto libraries – możesz użyć z Pulumi. W Terraform jesteś ograniczony do HCL functions. Kluczowe concepts Pulumi:

1. Resources – jak w Terraform, ale jako klasy/obiekty:

const bucket = new aws.s3.Bucket("my-bucket", {
  acl: "private",
  versioning: { enabled: true },
});

2. Outputs – asynchroniczne (Promise-based w TS, Future w Python):

const bucketName = bucket.id; // Output<string>
// Możesz użyć .apply() do transformacji
const url = bucket.id.apply(id => `https://${id}.s3.amazonaws.com`);

3. Stacks – environments (dev, staging, prod) jako separate stacks:

pulumi stack init dev
pulumi stack init prod
# Każdy stack ma własny state

4. Component Resources – reusable abstractions (jak Terraform modules, ale potężniejsze):

class WebServer extends pulumi.ComponentResource {
  public readonly instance: aws.ec2.Instance;
  public readonly publicIp: pulumi.Output<string>;

  constructor(name: string, args: WebServerArgs, opts?: pulumi.ComponentResourceOptions) {
    super("custom:WebServer", name, {}, opts);

    this.instance = new aws.ec2.Instance(`${name}-instance`, {
      ami: args.ami,
      instanceType: args.instanceType,
    }, { parent: this });

    this.publicIp = this.instance.publicIp;
  }
}

// Użycie
const webServer = new WebServer("my-app", {
  ami: "ami-12345678",
  instanceType: "t3.medium",
});

Pulumi vs Terraform – key differences:

Aspekt	Terraform/OpenTofu	Pulumi
Language	HCL (DSL)	TypeScript, Python, Go, C#, Java, YAML
Loops/logic	Limited (count, for_each)	Full language power
IDE support	via LSP	Native (TypeScript/Python/Go tooling)
Testing	terraform test (basic)	Unit tests (Jest, pytest, Go testing)
Providers	4800+	150+ (ale pokrywa mainstream use cases)
State management	terraform.tfstate (JSON)	Pulumi state (JSON, ale różna struktura)
Secrets	External (Vault, AWS Secrets Manager)	Built-in encrypted secrets
Modules/reuse	Terraform modules (HCL)	Packages (npm, PyPI, Go modules)

1. Team skills – zespół zna TypeScript/Python, nie chce uczyć się HCL

2. Complex logic – dynamiczne tworzenie resources na podstawie API calls, złożone conditionals

3. Testing culture – chcesz unit testy infrastruktury w CI/CD

4. Polyglot team – różne języki dla różnych componentów (TypeScript dla frontend infra, Python dla ML infra, Go dla platform team)

5. Internal abstractions– budujesz internal platform z high-level abstractions (np. deployWebApp() zamiast 50 low-level resources) Ryzyka z Pulumi:

6. Mniejszy ekosystem providerów – 150 vs 4800. Dla AWS/Azure/GCP/K8s bez problemu. Dla niszowych SaaSów może brakować.

7. Mniejsze community – mniej tutoriali, Stack Overflow answers. Hiring “Pulumi experience” trudniejszy.

8. State migration pain – jeśli masz Terraform state, migracja do Pulumi nie jest trivial (więcej w sekcji o migracji).

9. Imperative temptation – łatwo napisać kod Pulumi imperatywnie (loops tworzące resources dynamicznie), co komplikuje reasoning o state.

10. Provider lag – nowe features w AWS/Azure są czasem dostępne w Terraform provider wcześniej niż w Pulumi (bo Pulumi często bazuje na Terraform providers przez bridge).

Tabela porównawcza: Terraform vs Pulumi vs OpenTofu

Kompleksowe zestawienie – wszystkie kryteria wyboru w jednym miejscu:

Kryterium	Terraform	OpenTofu	Pulumi
License	BSL 1.1 (commercial restrictions)	MPL 2.0 (open-source)	Apache 2.0 (open-source)
Governance	HashiCorp (single vendor)	Linux Foundation + community	Pulumi Corp + community
Language	HCL (DSL)	HCL (DSL)	TypeScript, Python, Go, C#, Java, YAML
Providers	4800+	4200+ (Terraform compatible)	150+ (native + Terraform bridge)
Learning curve	Średnia (HCL do nauki)	Średnia (HCL do nauki)	Niska (jeśli znasz TS/Python/Go)
IDE support	via LSP (średni)	via LSP (średni)	Native (świetny)
Testing	terraform test (basic)	tofu test (improved)	Unit tests (full framework)
State encryption	External tools	Built-in (1.7+)	Built-in
Secrets management	External (Vault, etc.)	External	Built-in encrypted
Managed SaaS	Terraform Cloud ($$$)	Third-party (env0, Spacelift)	Pulumi Cloud (free tier + paid)
Community size	Największe	Rosnące (young)	Średnie
GitHub Stars	42K+	21K+	20K+
Maturity	12 lat (2014-2026)	3 lata (2023-2026)	8 lat (2018-2026)
Performance (large state)	Średni (1000+ resources slow)	Improved (early evaluation)	Średni
CI/CD integration	Świetny (native support)	Świetny (compatible)	Świetny (GitHub Actions, GitLab CI)
Multi-cloud	Świetny	Świetny	Dobry (limited providers)
Migration from Terraform	N/A	Trivial (drop-in)	Medium (converter + refactor)
Hiring pool	Największy	Rosnący	Mniejszy
Vendor lock-in risk	Średni (BSL concerns)	Niski (Linux Foundation)	Niski (Apache 2.0)
Best for	Enterprise z dużym ekosystemem, Terraform Cloud users	Teams with licensing concerns, Terraform users wanting open-source	Dev teams fluent in TS/Python/Go, complex logic, testing culture

Test setup: 500 EC2 instances + security groups + networking (VPC, subnets, routes). Czas plan + apply na clean state. Hardware: GitHub Actions runner (2 CPU, 7GB RAM). Region: us-east-1.

Narzędzie	Plan time	Apply time	Total
Terraform 1.8	3m 42s	12m 18s	16m 00s
OpenTofu 1.7	3m 28s	11m 54s	15m 22s
Pulumi 3.112 (TypeScript)	4m 10s	12m 05s	16m 15s

OpenTofu wygrywa minimalnie (early evaluation optimization). W praktyce różnice są nieistotne – bottleneck to AWS API rate limits, nie narzędzie.

Który narzędzie kiedy? Drzewo decyzyjne

Oto decision tree – odpowiadaj na pytania, dotrzyj do rekomendacji:

START: Czy masz już wdrożony Terraform?

TAK → Czy Terraform < 1.6?

• TAK: Rozważ migrację do OpenTofu (drop-in replacement, 0 zmian w kodzie)

  • Powód: unikasz lock-in na BSL license, zyskujesz open-source guarantees
  • Koszt migracji: ~1-2 dni (zmiana CI/CD, testing)

• NIE (Terraform 1.6+): Zostań przy Terraform, chyba że:

  • BSL license jest problemem dla Twojego business model → migruj do OpenTofu
  • Team ma silne preferencje pro-open-source → migruj do OpenTofu
  • Chcesz state encryption bez external tools → migruj do OpenTofu (ma built-in) NIE (nowy projekt) → Jakie są skills Twojego zespołu?

Team zna dobrze TypeScript/Python/Go i chce testować infrastrukturę jak kod aplikacyjny: → Pulumi

• Szczególnie jeśli:
  • Budujesz internal platform z high-level abstractions
  • Masz complex logic (dynamiczne tworzenie resources, API integrations)
  • Używasz mainstream cloud providers (AWS, Azure, GCP, K8s) – provider coverage OK

Team preferuje DSL, chce największy ekosystem providerów: → OpenTofu lub Terraform

• OpenTofu jeśli:

  • Nie chcesz vendor lock-in (open-source preference)
  • Planujesz długoterminowe użycie (10+ lat) i martwisz się o licensing changes
  • Nie potrzebujesz Terraform Cloud (możesz użyć env0, Spacelift lub self-host)

• Terraform jeśli:

  • Terraform Cloud fit do Twojego workflow i nie martwi Cię vendor lock-in
  • Potrzebujesz absolutnie każdego providera z Terraform Registry (niszowe SaaSy)
  • BSL license nie jest problemem dla Twojego modelu biznesowego

Szczególne przypadki:

Multi-cloud (AWS + Azure + GCP):

• Terraform/OpenTofu – najlepszy provider coverage dla wszystkich 3
• Pulumi– OK, ale niektóre niszowe features mogą brakować Heavy Kubernetes:
• Pulumi – świetne Kubernetes support, możesz pisać helm charts w TypeScript
• Terraform/OpenTofu– Kubernetes provider jest OK, ale YAML-in-HCL jest clunky Large enterprise (1000+ inżynierów, compliance heavy):
• Terraform – Terraform Cloud ma enterprise features (RBAC, audit logs, policy as code)
• OpenTofu– OK jeśli self-hostujecie lub używacie env0/Spacelift Enterprise Startup (szybka iteracja, small team):
• Pulumi – jeśli team zna TypeScript/Python, szybsze iteracje niż uczenie się HCL
• OpenTofu– jeśli wolisz stabilność ekosystemu Terraform Regulowana branża (finanse, healthcare):
• OpenTofu – gwarancja open-source, no licensing surprises
• Terraform – OK jeśli masz legal approval dla BSL

Migracja między narzędziami IaC

Masz legacy Terraform i chcesz migrować? Oto przewodnik dla każdej ścieżki:

Terraform → OpenTofu

Difficulty: 1/5 (trivial)

OpenTofu to drop-in replacement dla Terraform ≤ 1.5.x. Dosłownie zmienia się binary.

Migration steps:

1. Install OpenTofu:

# macOS (Homebrew)
brew install opentofu

# Linux (apt)
sudo apt install opentofu

# Verify
tofu version

2. Replace terraform command with tofu:

W CI/CD (np. GitHub Actions):

# Było:
- name: Terraform Plan
  run: terraform plan

# Jest:
- name: OpenTofu Plan
  run: tofu plan

W local development:

# Alias (dodaj do ~/.bashrc lub ~/.zshrc)
alias terraform="tofu"

3. Update state backend (jeśli używasz Terraform Cloud):

Terraform Cloud nie działa z OpenTofu. Musisz zmienić backend na:

• S3 + DynamoDB (AWS)
• Azure Storage Account (Azure)
• GCS (GCP)
• Self-hosted env0, Spacelift, lub Atlantis

Migration state z Terraform Cloud:

# 1. Zmień backend w *.tf na S3
terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

# 2. Pull state z Terraform Cloud
terraform state pull > terraform.tfstate

# 3. Push do nowego backend
tofu init -migrate-state

4. Testing:

# Sprawdź że plan jest czysty (no changes)
tofu plan
# Expected output: No changes. Your infrastructure matches the configuration.

5. Rollout:

• Start z non-prod environment (dev/staging)
• Monitor przez 1-2 tygodnie
• Rollout do prod

Time estimate: 1-2 dni dla small-to-medium infrastructure (< 500 resources). 1 tydzień dla large enterprise (testing, compliance approval). Gotchas:

• OpenTofu 1.7+ ma features których Terraform 1.5 nie ma (state encryption). Jeśli użyjesz, nie możesz rollback do Terraform.
• Niektóre providers mogą mieć lekko inne wersje w OpenTofu Registry vs Terraform Registry. Pin versions w required_providers.

Terraform → Pulumi

Difficulty: 3/5 (medium – converter + refactoring)

Pulumi ma tf2pulumi converter, ale migracja nie jest one-click. State jest inny, język jest inny.

Migration steps:

1. Convert HCL do Pulumi code:

# Install Pulumi
curl -fsSL https://get.pulumi.com | sh

# Install tf2pulumi
pulumi plugin install converter terraform

# Convert
tf2pulumi --target-language typescript ./terraform-code --out ./pulumi-code

Converter generuje TypeScript/Python/Go z Terraform HCL. Ale:

• Output jest często ugly – mechanical translation, nie idiomatyczny kod
• Trzeba refactoring dla czytelności
• Moduły Terraform nie zawsze konwertują się cleanly

2. Create new Pulumi project:

cd pulumi-code
pulumi new aws-typescript # lub aws-python
# Kopiuj wygenerowany kod do src/

3. Import existing resources do Pulumi state:

To jest crux migracji. Infrastruktura istnieje w AWS/Azure/GCP, zarządzana przez Terraform state. Musisz przenieść ownership do Pulumi state.

Opcja A: Import individual resources (manual):

pulumi import aws:ec2/instance:Instance my-server i-1234567890abcdef0

For 500 resources – painful. Ale controllable.

Opcja B: Bulk import via script:

// import-script.ts
import * as pulumi from "@pulumi/pulumi";
import * as aws from "@pulumi/aws";

// Parse Terraform state
const tfState = JSON.parse(fs.readFileSync("terraform.tfstate", "utf-8"));

for (const resource of tfState.resources) {
  if (resource.type === "aws_instance") {
    const instance = new aws.ec2.Instance(resource.name, {
      // ... extract attributes from tfState
    }, { import: resource.instances[0].attributes.id });
  }
}

Opcja C: Use Pulumi Terraform bridge (hybrid approach):

Możesz użyć Terraform state z Pulumi przez @pulumi/terraform:

import * as terraform from "@pulumi/terraform";

const tfState = new terraform.state.RemoteStateReference("my-tf-state", {
  backendType: "s3",
  bucket: "my-terraform-state",
  key: "prod/terraform.tfstate",
  region: "us-east-1",
});

// Reference outputs
const vpcId = tfState.getOutput("vpc_id");

To pozwala na gradual migration – część infra w Terraform, część w Pulumi, shared state.

4. Testing:

pulumi preview
# Verify no unexpected changes

5. Refactor for idiomaticity:

Mechanical conversion daje kod jak:

// Ugly (converter output)
const instance1 = new aws.ec2.Instance("instance-0", {...});
const instance2 = new aws.ec2.Instance("instance-1", {...});
const instance3 = new aws.ec2.Instance("instance-2", {...});

Refactor to:

// Clean (idiomatic Pulumi)
const instances = [0, 1, 2].map(i =>
  new aws.ec2.Instance(`instance-${i}`, {...})
);

Time estimate: 2-4 tygodnie dla medium infrastructure (200-500 resources). 2-3 miesiące dla large enterprise (1000+ resources, compliance, testing). Gotchas:

• State structure jest incompatible – nie możesz reuse Terraform state w Pulumi. Musisz import resources.
• Provider versions mogą różnić się (Pulumi używa Terraform providers przez bridge, ale bridge może być za AWS/Azure SDK).
• Testing critical – easy to accidentally recreate resources jeśli import nie zadziała perfectly.

OpenTofu → Pulumi

To samo co Terraform → Pulumi (OpenTofu state format jest identyczny jak Terraform).

Pulumi → Terraform/OpenTofu

Difficulty: 4/5 (hard – no converter, manual rewrite)

Pulumi nie ma convertera do HCL. Musisz:

1. Rewrite infrastructure code z TypeScript/Python do HCL
2. Import resources do Terraform/OpenTofu state

Similar process jak Terraform → Pulumi, ale w reverse. Brak automation tools. Budget 2x time estimate.

Jakie kompetencje IaC rozwijać w zespole?

IaC to nie tylko znajomość narzędzia (Terraform/Pulumi/OpenTofu). To szerszy skillset łączący infrastrukturę, security, software engineering.

Kompetencje kluczowe dla IaC practitioners:

1. Version Control (Git)

Co potrzeba:

• Branching strategies (GitFlow, trunk-based development)
• Pull request workflow + code review
• Merge conflicts resolution (szczególnie w state files – choć ich nie commitujemy, trzeba rozumieć)
• Git hooks (pre-commit dla terraform fmt, validation)

Dlaczego krytyczne: Infrastruktura w Git to foundation IaC. Zespół musi rozumieć Git workflows – infrastructure changes reviewowane są jak application code.

Training:

• Git for infrastructure engineers (2 dni) – basics + IaC-specific patterns
• Code review best practices (1 dzień) – co reviewować w IaC (security, cost, compliance)

2. Cloud Platforms (AWS/Azure/GCP)

Co potrzeba:

• Networking (VPC, subnets, routing, security groups, NACLs)
• Compute (EC2, ECS, EKS, Lambda, App Service, Cloud Run)
• Storage (S3, EBS, Azure Storage, Cloud Storage)
• IAM (policies, roles, service accounts, least privilege)
• Managed services (RDS, DynamoDB, CosmosDB, Firestore)

Level needed: Intermediate – nie musisz być cloud architect, ale musisz rozumieć co provisioning i jak komponenty interact. Training:

• AWS/Azure/GCP Fundamentals (3-5 dni per cloud) – dla DevOps/Platform engineers
• Networking for cloud engineers (2 dni) – VPC design, security groups, routing
• IAM and security best practices (2 dni) – least privilege, policy design

3. IaC Tool Proficiency (Terraform/OpenTofu/Pulumi)

Co potrzeba:

Terraform/OpenTofu:

• HCL syntax (resources, variables, outputs, locals, data sources)
• Modules – tworzenie reusable components
• State management – remote state, locking, state manipulation (import, mv, rm)
• Workspaces vs separate state files (design patterns)
• Provider configuration – versions, aliases (multi-region/multi-account)
• Loops i conditionals (count, for_each, dynamic blocks)

Pulumi:

• Język główny (TypeScript/Python/Go) – OOP, async/await
• Pulumi concepts (Resources, Outputs, ComponentResources, Stacks)
• Package management (npm/PyPI/Go modules)
• Testing (unit tests, integration tests, mocking)
• Pulumi Automation API (programmatic infrastructure deployments)

Level needed: Advanced dla senior/lead, operational dla mid-level engineers. Training:

• Terraform/OpenTofu Deep Dive (5 dni) – od basics po advanced patterns
• Pulumi for TypeScript developers (4 dni) – jeśli team wybiera Pulumi
• IaC best practices (2 dni) – DRY, immutability, blue-green deployments

4. Security i Compliance

Co potrzeba:

• Secrets management – Vault, AWS Secrets Manager, Azure Key Vault, nigdy hardcoded
• Least privilege IAM – roles z minimum permissions
• Encryption – at rest (S3, EBS) i in transit (TLS)
• Network security – security groups, NACLs, private subnets
• Compliance frameworks – CIS Benchmarks, SOC2, ISO27001, GDPR
• Policy as code – Sentinel (Terraform Cloud), OPA (Open Policy Agent), Pulumi Policy Packs

Typowe błędy security w IaC:

• Hardcoded secrets w .tf files (commit do Git = game over)
• Overly permissive security groups (0.0.0.0/0 na production)
• Public S3 buckets (default powinien być private)
• Brak encryption na EBS volumes
• IAM policies z * actions (zbyt szerokie permissions)

Level needed: Intermediate – każdy IaC practitioner musi znać security basics. Security specialists – advanced. Training:

• Security in IaC (3 dni) – secrets, IAM, encryption, network security
• Policy as code (2 dni) – Sentinel / OPA, compliance automation
• Cloud security best practices (3 dni) – AWS/Azure/GCP security services

5. CI/CD Integration

Co potrzeba:

• CI/CD platforms (GitHub Actions, GitLab CI, Jenkins, CircleCI)
• Pipeline design – stages (validate, plan, apply), approvals
• Remote state w CI/CD – backend configuration, locking
• Secrets w CI/CD – GitHub Secrets, GitLab CI/CD variables, Vault integration
• Drift detection – scheduled runs checking state vs reality
• PR-based workflows – plan on PR, apply on merge

Best practice pipeline:

# .github/workflows/terraform.yml
name: Terraform
on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  plan:
    runs-on: ubuntu-latest
    if: github.event_name == 'pull_request'
    steps:
      - uses: actions/checkout@v3
      - uses: hashicorp/setup-terraform@v2
      - run: terraform init
      - run: terraform fmt -check
      - run: terraform validate
      - run: terraform plan
      # Post plan to PR comment

  apply:
    runs-on: ubuntu-latest
    if: github.event_name == 'push' && github.ref == 'refs/heads/main'
    steps:
      - uses: actions/checkout@v3
      - uses: hashicorp/setup-terraform@v2
      - run: terraform init
      - run: terraform apply -auto-approve

Level needed: Operational – każdy w zespie IaC musi rozumieć CI/CD workflow. Training:

• CI/CD for infrastructure (2 dni) – GitHub Actions/GitLab CI, pipeline design
• GitOps patterns (1 dzień) – trunk-based development, PR workflows

6. Testing i Validation

Co potrzeba:

Syntax validation:

• terraform fmt – formatting
• terraform validate – syntax check

Unit testing:

• Terratest (Go) – dla Terraform modules
• Pulumi unit tests (Jest, pytest) – mock resources, test logic

Integration testing:

• Deploy do test environment, run smoke tests, tear down
• Kitchen-Terraform – test infrastructure w ephemeral environments

Policy testing:

• Sentinel / OPA policies – enforce compliance rules (np. “all S3 buckets must have encryption”)

Level needed: Operational dla validation, intermediate dla unit/integration tests. Training:

• Testing IaC (2 dni) – validation, unit tests, integration tests
• Policy as code (2 dni) – Sentinel/OPA, compliance automation

7. Troubleshooting i Debugging

Co potrzeba:

• Reading state files (terraform state list, state show)
• Debugging provider issues (TF_LOG=DEBUG)
• Resolving state conflicts (state locking, force-unlock)
• Importing existing resources (terraform import)
• State surgery (state mv, state rm) – last resort, ale czasem konieczne

Common issues:

• State drift – ktoś zmienił infrastrukturę ręcznie, state outdated → terraform plan pokazuje unexpected changes
• State lock – inny proces trzyma lock → terraform force-unlock
• Provider version conflicts – upgrade Terraform/provider broke compatibility → pin versions
• Cyclic dependencies– resource A depends on B depends on A → redesign Level needed: Advanced dla senior engineers, awareness dla wszystkich. Training:
• IaC troubleshooting (1 dzień) – common issues, debugging techniques
• State management deep dive (1 dzień) – state surgery, import, migration

Matryca kompetencji dla ról:

Kompetencja	Junior IaC Engineer	Mid IaC Engineer	Senior/Lead IaC Engineer	Platform Architect
Version Control	Operational	Advanced	Advanced	Expert
Cloud Platforms	Awareness	Operational	Advanced	Expert
IaC Tool	Operational	Advanced	Expert	Expert
Security	Awareness	Operational	Advanced	Expert
CI/CD	Awareness	Operational	Advanced	Expert
Testing	Operational	Operational	Advanced	Expert
Troubleshooting	Awareness	Operational	Advanced	Expert

Junior IaC Engineer (0-2 lata doświadczenia):

• Focus: Podstawy Terraform/Pulumi, cloud platforms basics, Git workflow
• Szkolenia: 80h w ciągu 6 miesięcy (Terraform Fundamentals, AWS/Azure Basics, Git for Engineers)
• Projekty: Prosty infrastructure (EC2, S3, RDS) pod supervizją seniora Mid IaC Engineer (2-4 lata):
• Focus: Moduły, security best practices, CI/CD integration
• Szkolenia: 60h w ciągu 12 miesięcy (Security in IaC, CI/CD for Infrastructure, Terraform Advanced)
• Projekty: Multi-tier applications, multi-region, team collaboration Senior IaC Engineer (4+ lat):
• Focus: Architecture design, policy as code, mentoring juniors
• Szkolenia: 40h w ciągu 12 miesięcy (Policy as Code, Advanced Cloud Architecture, Leadership)
• Projekty: Platform design, internal tooling, standards dla organizacji

Podsumowanie – Terraform, OpenTofu czy Pulumi w 2026?

Trzy lata po BSL license change rynek IaC się ustabilizował. Masz trzy solidne opcje – każda z innym trade-off:

Terraform: ✓ Największy ekosystem providerów (4800+) ✓ Terraform Cloud jako managed SaaS ✓ Najłatwiejszy hiring (największy talent pool) ✗ BSL license – vendor lock-in concerns ✗ Single vendor control (HashiCorp)

OpenTofu: ✓ Open-source guarantee (Linux Foundation) ✓ Drop-in replacement dla Terraform ≤1.5 (trivial migration) ✓ Community governance + features beyond Terraform (state encryption) ✗ Młodsze narzędzie (3 lata) – mniejsze community, mniej tutoriali ✗ Brak official managed SaaS (trzeba użyć third-party)

Pulumi: ✓ Real programming languages (TypeScript, Python, Go) ✓ Native IDE support, unit testing, package ecosystem ✓ Powerful abstractions (ComponentResources) ✗ Mniejszy ekosystem providerów (150 vs 4800) ✗ Mniejszy talent pool, trudniejszy hiring ✗ Migration z Terraform nie jest trivial

Rekomendacja:

Dla nowych projektów:

• OpenTofu jeśli chcesz HCL + open-source guarantees + największy ekosystem
• Pulumi jeśli team zna TypeScript/Python i chce testować infrastructure jak kod aplikacyjny Dla istniejącego Terraform:
• OpenTofu jeśli martwi Cię BSL license (migracja = 1-2 dni)
• Terraform jeśli BSL nie jest problemem i używasz Terraform Cloud Dla enterprise z compliance concerns:
• OpenTofu– gwarancja open-source, brak licensing surprises Dla startupów z dev team znającym TypeScript:
• Pulumi – szybsza iteracja, mniej learning curve (no HCL)

Nie ma “złego” wyboru – wszystkie trzy narzędzia są production-ready w 2026. Kluczowe to dopasowanie do Twojego team skills, compliance requirements i długoterminowej strategii.

Twój następny krok: kompetencje IaC w zespole

Wybór narzędzia to jedno. Drugie – to upskilling zespołu. IaC to nie tylko znajomość Terraform/Pulumi, ale security, CI/CD, cloud platforms, version control. Według naszych danych z 2500+ szkoleń DevOps, 68% firm podchodzi do IaC ad-hoc – “nauczą się sami z tutoriali”. Rezultat? Tech debt w infrastructure code, security issues, brak standardów.

Structured learning path robi różnicę. Zespół z 40-80h szkoleń IaC (Terraform + Security + CI/CD) deliveruje infrastructure 3x szybciej i z 80% mniej security incidents niż zespoły self-taught (dane z 150 firm, których szkoliliśmy w latach 2023-2025).

Gotowy zbudować kompetencje IaC w swoim zespole?

Skontaktuj się z EITT – przeprowadzimy bezpłatny skills assessment i zaprojektujemy program szkoleń dopasowany do Twojego zespołu (Terraform, OpenTofu lub Pulumi). 500+ ekspertów, 2500+ przeprowadzonych szkoleń, 4.8/5 średnia ocena.

Alternatywnie: zobacz nasze szkolenia z obszaru DevOps, Terraform, cloud platforms (AWS/Azure/GCP) i CI/CD.

Twoja infrastruktura powinna być kodem. Twój zespół powinien mieć kompetencje, żeby ten kod był production-grade.

Przeczytaj również

• Pulumi: infrastruktura jako kod – jak zarządzać zasobami w chmurze?
• Certyfikaty cyberbezpieczeństwa - CISSP, CEH, Security+ porównanie
• Od pomysłu do prototypu: praktyczne narzędzia design thinking wspierające innowacyjność zespołów

Rozwijaj swoje kompetencje

Chcesz pogłębić wiedzę z tego obszaru? Sprawdź nasze szkolenie prowadzone przez doświadczonych trenerów EITT.

➡️ Pulumi - infrastruktura jako kod — szkolenie EITT

Najczęściej zadawane pytania

Czy migracja z Terraform do OpenTofu wymaga zmian w kodzie?

Nie, migracja z Terraform do OpenTofu jest typu drop-in replacement i nie wymaga żadnych zmian w kodzie HCL. OpenTofu zachowuje 100% kompatybilności wstecznej z Terraform 1.5.x, więc wystarczy zmienić binarkę i kontynuować pracę z istniejącymi plikami konfiguracyjnymi.

Które narzędzie IaC jest najlepsze dla zespołu bez doświadczenia z HCL?

Pulumi będzie najlepszym wyborem dla zespołów, które nie znają HCL, ale mają doświadczenie z językami programowania takimi jak TypeScript, Python, Go czy C#. Pozwala pisać infrastrukturę w znanym języku, co skraca czas nauki i umożliwia wykorzystanie istniejących umiejętności programistycznych.

Czy zmiana licencji Terraform na BSL 1.1 wpływa na typowe użycie w firmie?

Dla większości użytkowników końcowych zmiana licencji Terraform na Business Source License 1.1 nie ma bezpośredniego wpływu na codzienną pracę. Ograniczenia dotyczą głównie firm budujących konkurencyjne produkty wobec HashiCorp. Warto jednak rozważyć długoterminowe ryzyko vendor lock-in i mieć plan awaryjny.

Czy można łączyć Terraform i Pulumi w jednym projekcie?

Tak, jest to możliwe i stosowane w praktyce. Pulumi potrafi odczytywać state Terraform, a oba narzędzia mogą zarządzać różnymi częściami infrastruktury. Takie podejście sprawdza się przy stopniowej migracji lub gdy różne zespoły preferują różne narzędzia.