Cloud computing er nå en av de tre største teknologitrendene i Norge, side om side med kunstig intelligens og Creative Commons, med en samlet målgruppe på 1,3 millioner mennesker, ifølge søkedata fra Rascasse (oppdatert 17. august 2026). Når flere nordiske team bygger og automatiserer skyinfrastruktur, dukker samme spørsmål opp igjen og igjen: Terraform eller Pulumi?
Begge verktøyene løser den samme grunnoppgaven. De lar deg beskrive skyressurser som kode og bygge dem automatisk, i stedet for å klikke dem sammen i et konsoll. Men de gjør det på helt forskjellige måter, og i 2026 er forskjellene tydeligere enn før, etter at HashiCorp endret prismodellen for HCP Terraform og Pulumi fortsatte å bygge ut sin programmerbare plattform rundt ordinære programmeringsspråk.
Terraform har vært standardvalget i nesten et tiår. Ifølge Stack Overflow sin utviklerundersøkelse for 2026 bruker 18,3 % av de 10 889 respondentene som svarte på spørsmål om skyutvikling verktøyet. Pulumi ligger langt bak med 2,0 %, men andelen har mer enn doblet seg siden 2023, da bare 0,82 % svarte at de brukte det. Den veksten, sammen med at selskaper som Wiz, Starburst og BMW nå kjører produksjonsmiljøer på Pulumi, er grunnen til at valget fortjener en ny gjennomgang akkurat nå.
Denne sammenligningen går gjennom arkitektur, lisens, pris, sikkerhet, ytelse og konkrete migreringssteg, slik at du kan ta en beslutning som passer teamet ditt, ikke bare følge det som er mest brukt. Den er skrevet for plattformteam, DevOps-ingeniører og tekniske ledere som allerede kjenner grunnprinsippene i infrastruktur som kode, men som trenger oppdaterte, kildebelagte tall for å ta et informert valg i 2026, ikke en generell innføring i hva IaC er.
Hva er Terraform?
Terraform er HashiCorps verktøy for infrastruktur som kode. Du beskriver skyressurser i HashiCorp Configuration Language (HCL), et språk bygget spesifikt for konfigurasjon, og kjører terraform plan og terraform apply for å se og gjennomføre endringer. HCL er kompakt og deklarativt, men det setter klare grenser for abstraksjon med design. Det finnes ingen klasser og begrenset kjøretidslogikk, og gjenbruk skjer gjennom modulsystemet og Terraform Registry, der HashiCorp og fellesskapet publiserer ferdige byggeklosser for AWS, Azure, Google Cloud og hundrevis av andre tjenester.
Et viktig poeng mange overser: Terraform er ikke lenger åpen kildekode i streng forstand. Siden versjon 1.6 distribueres Terraform CLI under Business Source License 1.1, en lisens som begrenser hvordan konkurrenter kan bruke koden kommersielt. Det var denne endringen som utløste opprettelsen av OpenTofu, en fullstendig åpen kildekode-fork under MPL-2.0-lisensen, nå forvaltet av Linux Foundation.
For teamarbeid i skala tilbyr HashiCorp HCP Terraform (tidligere Terraform Cloud) og Terraform Enterprise som kommersielle produkter. Disse legger til eksternt kjørte planer og applyer, tilstandslagring, rollebasert tilgang og policystyring via Sentinel eller Open Policy Agent. Testing dekkes av det innebygde rammeverket terraform test, som kjører egne testfiler med filtypen .tftest.hcl mot plan- eller apply-resultater, samt det tredjepartsbiblioteket Terratest for Go-baserte integrasjonstester.
Når noe allerede eksisterer i skyen uten å være kjent for Terraform, løses det med terraform import eller et import-blokk i koden. Selve HCL-koden som beskriver ressursen må som regel skrives manuelt, selv om kommandoen terraform plan -generate-config-out kan generere et utkast å jobbe videre med. Hvis en apply mislykkes halvveis, blir arbeidsområdet stående i en delvis oppdatert tilstand, og en ny apply forsøker å forsone seg mot ønsket sluttresultat. Det finnes ingen egen rollback-kommando, men du kan rulle fremover ved å reversere endringer i koden og kjøre på nytt.
Hva er Pulumi?
Pulumi løser samme problem, men lar deg skrive infrastrukturkoden i Python, TypeScript, JavaScript, Go, .NET, Java, YAML, eller i HCL hvis du vil beholde den syntaksen. Kjernen, altså Pulumi CLI og SDK-ene, er åpen kildekode under Apache License 2.0, og kan brukes fritt uten binding til et bestemt skybakende.
Siden Pulumi-programmer er vanlig kode, testes de med rammeverkene teamet allerede bruker til applikasjonskode, som Jest, pytest, Go sitt innebygde testpakke eller xUnit. Enhetstester kan mocke selve motoren slik at de kjører uten skykreditiver, mens integrasjonstester ruller ut reelle stabler og sjekker resultatet. Det finnes også en programmerbar Automation API, et SDK som lar team bygge egne CLI-er, interne utviklerplattformer og tjenester som setter opp midlertidige miljøer uten å kalle ut til Pulumi-kommandolinjen i et skall. Terraform har ingen direkte parallell til dette.
Pulumi Cloud, den kommersielle delen, forvalter tilstand som standard og legger til samarbeid, revisjonslogger, policy-som-kode og noe HashiCorps løsning ikke gjør: Pulumi Cloud kan også fungere som tilstandslagring og ekstern kjøremotor for eksisterende Terraform- og OpenTofu-prosjekter, uten at du konverterer en eneste konfigurasjonsfil. Det gjør Pulumi til et reelt alternativ selv for team som i dag er dypt investert i HCL.
Gjenbruk løses med det Pulumi kaller Component Resources, byggeklosser skrevet i et hvilket som helst støttet språk. Gjennom Pulumi Packages kan en komponent skrevet i, for eksempel, Go, konsumeres fra et Pulumi-program skrevet i Python eller TypeScript. Import av eksisterende ressurser skjer med pulumi import eller et import-alternativ i koden, og begge genererer ferdig kode i teamets valgte språk automatisk, i stedet for at du må skrive konfigurasjonen for hånd. På policysiden tilbyr Pulumi Policies, som er åpen kildekode, ferdige policypakker for rammeverk som CIS, HITRUST, NIST og PCI DSS gjennom de kommersielle Pulumi Cloud-planene, nyttig for team som må dokumentere etterlevelse av bransjestandarder.
HCL mot ekte programmeringsspråk: den store arkitekturforskjellen
Den klareste skillelinjen mellom verktøyene handler ikke om funksjonslister, men om hvilket språk du skriver i, og hva det språket lar deg gjøre. HCL er en domenespesifikk språk bygget for konfigurasjon. Den er lett å lese for folk med drift- og infrastrukturbakgrunn, men den begrenser bevisst logikk og abstraksjon. Løkker og betinget logikk finnes via spesialkonstruksjoner som for_each, count og dynamic, ikke som vanlig programmeringssyntaks.
Pulumi går motsatt vei. Et generelt programmeringsspråk gir vanlige løkker, betinget logikk, klasser, pakkehåndtering og IDE-funksjoner som autofullføring, typekontroll og refaktorering, altså alt utviklerne allerede er vant til fra applikasjonskode. Dette har også fått ny relevans med fremveksten av AI-kodeassistenter. De har sett enormt mye mer Python, TypeScript og Go enn HCL under trening, og genererer og refaktorerer derfor generell kode med langt høyere treffsikkerhet enn de gjør med en nisjespråk-DSL.
Samtidig er det ikke et rent enten-eller. Pulumi støtter HCL som ett av sine kjøremiljøer, kalt Pulumi HCL, som kan tolke gyldige Terraform- og OpenTofu-filer direkte med et kort dokumentert unntak av kanttilfeller. Et team kan altså flytte til Pulumis plattform og motor uten å skrive om en linje med .tf-kode, og heller gjøre overgangen til et generelt språk senere, i eget tempo. Begge veier finnes, og det gjør valget mindre skjebnebestemt enn det ofte fremstilles som.
Terraform mot Pulumi: full spesifikasjonstabell
Tabellen under samler de viktigste tekniske og forretningsmessige forskjellene side om side, basert på offisiell produktdokumentasjon fra begge leverandørene.
| Egenskap | Terraform | Pulumi |
|---|---|---|
| Konfigurasjonsspråk | HCL (domenespesifikt språk) | Python, TypeScript, JavaScript, Go, .NET, Java, YAML, og HCL |
| Lisens for kjerne-CLI | Business Source License 1.1 (ikke åpen kildekode siden v1.6) | Apache License 2.0 (åpen kildekode) |
| Standard tilstandslagring (state) | Lokale filer, eller eksterne backends som S3, Azure Blob Storage, Google Cloud Storage, Consul, HCP Terraform | Pulumi Cloud som standard, eller egne backends som S3, Azure Blob Storage, Google Cloud Storage, lokale filer |
| Kryptering av hemmeligheter i state | Ikke kryptert i state-filen som standard, krever HCP Terraform eller separat Vault-integrasjon | Kryptert i transitt og i ro som standard, med egen krypteringsnøkkel per stack og pluggbar KMS (AWS KMS, Azure Key Vault, Google Cloud KMS, HashiCorp Vault) |
| Programmerbart API for egne verktøy | Ingen tilsvarende løsning | Automation API, et SDK for å bygge egne CLI-er og plattformer |
| Innebygd testrammeverk | terraform test med egne .tftest.hcl-filer, pluss tredjepartsbiblioteket Terratest | Enhetstester i språkets eget rammeverk, som Jest, pytest, Go testing eller xUnit, med mockede ressurskall |
| Kjører den andres konfigurasjon | Kan peke mot Pulumi Cloud som ekstern backend uten konvertering | Kan tolke gyldige Terraform- og OpenTofu-filer direkte via Pulumi HCL-kjøremiljøet |
| Policy-som-kode | Sentinel eller Open Policy Agent, kun i HCP Terraform eller Terraform Enterprise | Pulumi Policies, åpen kildekode under Apache 2.0, skrevet i Python, TypeScript eller Rego |
| Selvhostet virksomhetsvariant | Terraform Enterprise | Selvhostet Pulumi Cloud |
| Modulbibliotek | Terraform Registry, med et stort og veletablert utvalg fra HashiCorp og fellesskapet | Pulumi Registry, pluss mulighet til å bruke eksisterende Terraform-providere direkte |
| Markedsandel (Stack Overflow 2026) | 18,3 % av respondentene | 2,0 % av respondentene |
Det klareste mønsteret i tabellen er at Terraform vinner på utbredelse, modulbibliotek og et etablert økosystem, mens Pulumi vinner på kryptering som standard, programmerbarhet og fleksibilitet i språkvalg. Ingen av dem er objektivt bedre på alle punkter, og det er nettopp derfor valget avhenger av hva teamet ditt allerede kan og hvilke krav sikkerhetspolicyen setter til hemmeligheter i hviletilstand.
Prising i 2026: Resources Under Management mot Pulumi Credits
Begge leverandørene har endret eller presisert prismodellen sin i 2026, og det gjør pris til et av de mest aktuelle sammenligningspunktene akkurat nå. HCP Terraform prises etter Resources Under Management (RUM), altså antall ressurser som finnes i tilstandsfilene plattformen forvalter, ikke antall brukere. Gratisnivået dekker opptil 500 forvaltede ressurser per organisasjon. Den gamle, brukerbaserte gratisplanen ble pensjonert 31. mars 2026, og eksisterende organisasjoner ble automatisk flyttet over til den nye ressursbaserte modellen.
Pulumi Cloud bruker i stedet utgaver (editions) med en fast månedlig grunnpris, der forbruk utover grunnpakken trekkes fra en pool av Pulumi Credits. Disse kredittene dekker flere ting samtidig: antall IaC-ressurser, bruk av Deployments (eksterne kjøringer), ESC (Environments, Secrets, and Configuration) og det AI-drevne infrastrukturagentverktøyet Neo. Pulumi Clouds gratisutgave inkluderer forvaltet tilstand uten ekstra kostnad, slik at enkeltpersoner og mindre team kan komme i gang uten å drifte sin egen backend.
| Prisaspekt | Terraform (HCP Terraform / Terraform Enterprise) | Pulumi (Pulumi Cloud) |
|---|---|---|
| Prismodell | Resources Under Management (RUM), basert på ressurser i state | Utgaver med fast grunnpris pluss forbrukte Pulumi Credits |
| Gratisnivå | Opptil 500 forvaltede ressurser per organisasjon | Forvaltet tilstand inkludert i gratisutgaven |
| Hva betalingsenheten dekker | Antall ressurser i state-filene | IaC-ressurser, Deployments, ESC og Neo-bruk samlet |
| Endring i 2026 | Gammel brukerbasert gratisplan pensjonert 31. mars 2026 | Sammenligningsdokumentasjon oppdatert 15. oktober 2026 |
| Selvhostet alternativ | Terraform Enterprise | Selvhostet Pulumi Cloud |
| Lisens for det du installerer selv | Business Source License 1.1 | Apache License 2.0 |
For et team som allerede kjenner antallet ressurser de forvalter, er RUM-modellen enkel å budsjettere med, noe som også gjør den lettere å få inn i et FinOps-budsjett. For team som bruker mange av Pulumis plattformfunksjoner samtidig, som automatiserte Git-drevne kjøringer og driftdeteksjon, kan kredittmodellen bli vanskeligere å anslå på forhånd, fordi flere ulike aktiviteter trekker fra samme pool. Begge leverandørene tilbyr dessuten en selvhostet variant for virksomheter som ikke kan eller vil legge tilstand og kjøringer hos en tredjepart, henholdsvis Terraform Enterprise og en selvhostet versjon av Pulumi Cloud, noe som er verdt å kjenne til for team med strenge krav til datalokasjon i Norge eller resten av Norden.
Markedsadopsjon: hvem bruker egentlig hva i 2026
Tallene fra Stack Overflows utviklerundersøkelse for 2026 gir det klareste bildet av hvor de to verktøyene faktisk står i markedet. Undersøkelsen spurte 10 889 respondenter om hvilke verktøy de bruker i skyutvikling, og resultatene strekker seg langt forbi bare infrastruktur som kode.
| Verktøy | Andel 2026 | Andel 2023 |
|---|---|---|
| Docker / Docker Compose | 59,1 % | – |
| Kubernetes | 26 % | – |
| Terraform | 18,3 % | 11,3 % |
| Podman | 13 % | – |
| Ansible | 12 % | – |
| Helm | 12,4 % | – |
| Rancher | 4,4 % | – |
| OpenTofu | 3,6 % | – |
| OpenShift | 3,2 % | – |
| Pulumi | 2,0 % | 0,82 % |
Som tabellen viser, er Terraform fortsatt mer enn ni ganger så mye brukt som Pulumi i absolutte tall. Men vekstraten forteller en annen historie. Terraforms andel steg fra 11,3 % til 18,3 % siden 2023, en økning på rundt 62 %. Pulumis andel gikk fra 0,82 % til 2,0 %, en økning på over 140 %, riktignok fra et mye lavere utgangspunkt.
Enda mer interessant er hva som skjer når man spør eksisterende brukere om hvor fornøyde de er, målt som en “admired”-score i samme undersøkelse, ifølge analysen hos Virtualization Review. OpenTofu, den åpne forken av Terraform, scoret 61,1 % i admired-kategorien, mot 45,7 % for Terraform selv. Dette betyr ikke at Pulumi vinner på tilfredshet, siden Pulumis egen admired-score ikke ble rapportert separat i den offentlige analysen, men det er et tydelig signal om at mange eksisterende Terraform-brukere er mer fornøyde med lisensfrie alternativer enn med selve originalverktøyet.
Stack Overflow selv oppsummerer bildet nøkternt: tallene representerer rapportert bruk blant respondentgruppen, og de slår ikke fast om en organisasjon faktisk har standardisert på et bestemt verktøy. Det er med andre ord mulig, og vanlig, at ett og samme team bruker både Terraform og Pulumi til forskjellige deler av stabelen.
Hva tallene fra undersøkelsene faktisk sier
Når man leser rapporteringen rundt Stack Overflows utviklerundersøkelse, er det verdt å gå til kildene direkte i stedet for å stole på en forenklet oppsummering. Stack Overflow oppsummerer selv resultatene fra 2026-undersøkelsen slik: “18,3 prosent av respondentene oppga at de bruker Terraform, mot 2,0 prosent som oppga at de bruker Pulumi.” Det samme materialet presiserer utvalgets størrelse: “Blant de 10 889 respondentene som svarte på spørsmålet om skyutvikling, ble Terraform brukt av 18,3 prosent og Pulumi av 2,0 prosent.”
Satt opp mot tidligere år blir trenden tydelig. I Stack Overflows egen rapportering fra 2023-undersøkelsen heter det: “I undersøkelsen for 2023 ble Terraform oppgitt av 11,3 prosent av alle respondenter, mens Pulumi ble oppgitt av 0,82 prosent av respondentene i den tilsvarende teknologikategorien.” Forskjellen mellom disse tallene er selve kjernen i denne sammenligningen. Begge verktøyene vokser i absolutt bruk, men Pulumi vokser fra en mye mindre base, og Terraform er fortsatt det klare flertallsvalget blant utviklere som faktisk svarer på slike undersøkelser.
Tilstand og hemmeligheter: hvor ligger dataene dine
Tilstandsfilen (state) er limet som holder infrastruktur som kode sammen. Den forteller verktøyet hva som allerede eksisterer i skyen, slik at neste apply eller up vet hva som må endres, legges til eller slettes. Terraform lagrer tilstand lokalt som standard, men de fleste team på teamnivå flytter raskt til en ekstern backend som S3, Azure Blob Storage, Google Cloud Storage, Consul, eller HCP Terraforms egen forvaltede tilstand.
Her ligger en av de mest undervurderte forskjellene mellom verktøyene. Terraform krypterer ikke sensitive verdier i selve tilstandsfilen som standard. HCP Terraform krypterer riktignok tilstanden ved lagring på serveren, og Vault-integrasjon finnes som et eget produkt, men det er et tillegg du må sette opp selv, ikke en innebygd egenskap i open source-verktøyet. Pulumi går motsatt vei fra start: hemmeligheter krypteres i transitt og i ro i tilstandsfilen som standard, med en egen krypteringsnøkkel per stack, og teamet kan koble på en pluggbar KMS-tjeneste som AWS KMS, Azure Key Vault, Google Cloud KMS eller HashiCorp Vault for nøkkelhåndtering.
For team som opererer i regulerte bransjer, som finans eller offentlig sektor, der kryptering av hemmeligheter ofte er et revisjonskrav og ikke en smakssak, kan dette alene være nok til å tippe valget. Samtidig har begge verktøyene nå en felles vei ut av dilemmaet: siden Pulumi Cloud kan fungere som tilstandslagring for Terraform og OpenTofu uten konvertering, kan et team beholde sin eksisterende HCL-kode og samtidig få kryptert tilstand, revisjonslogg, låsing og rollebasert tilgang, uten en full omskriving.
Testing, CI/CD og automatisering
Testing av infrastrukturkode har lenge vært et svakt punkt i hele IaC-feltet, og de to verktøyene angriper problemet forskjellig. Terraform har sitt innebygde rammeverk terraform test, som kjører egne .tftest.hcl-filer mot plan- eller apply-resultater og kan bruke mock-providere for å unngå å røre ekte infrastruktur. For mer omfattende integrasjonstester bruker mange team i stedet det tredjepartsbaserte Go-biblioteket Terratest.
Pulumi har ingen egen testspråk å lære, fordi koden allerede er skrevet i et generelt programmeringsspråk. Enhetstester kjøres i det samme rammeverket utviklerne bruker til applikasjonskode, enten det er Jest for TypeScript, pytest for Python, Go sin innebygde testpakke, eller xUnit for .NET. Disse testene mocker selve ressurskallene og kjører derfor helt uten skykreditiver, mens separate integrasjonstester faktisk ruller ut en stabel og verifiserer resultatet mot virkelige ressurser.
På automatiseringssiden tilbyr Pulumi Deployments Git-drevne kjøringer, gjennomgang av pull request-stabler, planlagte kjøringer og driftdeteksjon med forslag til utbedring, alt innenfor samme plattform. Terraform løser mye av dette via HCP Terraform eller Terraform Enterprise sine eksterne kjøringer, kombinert med vanlige CI/CD-pipeliner fra verktøy som GitHub Actions eller Azure DevOps. Begge veier fungerer i produksjon i dag, men Pulumis Automation API gir en ekstra mulighet: å bygge egne, skreddersydde CLI-er og interne plattformer som styrer infrastrukturlivssyklusen programmatisk, uten å kalle ut til en kommandolinje i et underskall.
Sikkerhet og etterlevelse: hva nordiske team bør vite
Infrastruktur som kode er ikke bare et produktivitetsverktøy, det er også et revisjonsobjekt. Når tilsynsmyndigheter eller interne compliance-team ber om dokumentasjon på hvordan skyressurser er konfigurert og endret over tid, er det tilstandsfilen, policyreglene og tilgangsloggene som avgjør hvor lang tid svaret tar. Her har de to verktøyene litt forskjellige utgangspunkt. HCP Terraform og Terraform Enterprise støtter Sentinel, HashiCorps proprietære policyspråk, i tillegg til Open Policy Agent, men begge er låst til de betalte produktene og ikke tilgjengelig i open source-kjernen.
Pulumi Policies er derimot åpen kildekode fra start, med regler skrevet i Python, TypeScript eller Open Policy Agent Rego, og de kommersielle Pulumi Cloud-planene legger til sentralisert policyhåndtering pluss ferdige, Pulumi-forvaltede policypakker for rammeverk som CIS, HITRUST, NIST og PCI DSS. For et team i finanssektoren eller offentlig forvaltning som allerede må dokumentere etterlevelse av et av disse rammeverkene, kan det spare betydelig tid å starte med en ferdig policypakke i stedet for å skrive reglene fra bunnen.
Dette blir ekstra relevant i Norden akkurat nå, fordi cloud computing allerede er en av de tre største teknologitrendene i Norge i 2026, med en samlet målgruppe på 1,3 millioner mennesker sammen med kunstig intelligens og Creative Commons, ifølge Rascasses søkedata. Flere ressurser i skyen betyr flere konfigurasjonsendringer å spore, flere hemmeligheter å beskytte, og flere policyregler å vedlikeholde. Valget mellom Terraform og Pulumi påvirker derfor ikke bare utviklerproduktivitet, men også hvor mye manuelt revisjonsarbeid et sikkerhetsteam må gjøre i etterkant, uavhengig av om infrastrukturen ligger hos AWS, Azure, Google Cloud eller en nordisk skyleverandør.
Fem virkelige eksempler: fra kode til produksjon
Teori og spesifikasjoner er nyttig, men det er resultatene i produksjon som faktisk avgjør om et verktøy holder. Her er fem konkrete, dokumenterte eksempler fra 2025 og 2026.
- Starburst byttet ut Terraform med Pulumi for sine flerregions Kubernetes-distribusjoner og kuttet utrullingstiden fra to uker til rundt tre timer, en forbedring på 112 ganger, ved å erstatte håndholdte HCL-limskript med Automation API-drevet orkestrering skrevet i Java.
- Wiz bruker Pulumis Automation API til å forvalte over én million skyressurser fordelt på tusenvis av Kubernetes-klynger verden over, og håndterer hundretusener av infrastrukturoppdateringer hver dag.
- BMWs Software Factory forvalter over 20 000 skyressurser med Python-basert infrastrukturkode, tett integrert i selskapets eksisterende CI/CD-arbeidsflyter.
- OpenTofu, den lisensfrie forken av Terraform forvaltet av Linux Foundation, nådde en bruksandel på 3,6 % i Stack Overflows 2026-undersøkelse bare noen år etter at lisensendringen i 2023 utløste opprettelsen, og eksisterende brukere gir forken en admired-score på 61,1 %, klart høyere enn Terraforms egne 45,7 %.
- Norges egen vekst i skyfeltet illustrerer hvorfor valget havner på flere bord: cloud computing rangerer nå blant de tre største teknologitrendene i landet, med en samlet målgruppe på 1,3 millioner mennesker side om side med kunstig intelligens, ifølge Rascasses søkedata fra august 2026.
Det er viktig å lese Starburst-, Wiz- og BMW-tallene for det de er: offentliggjorte kundecaser fra Pulumi selv, ikke uavhengige tredjepartsbenchmarker. Terraform har et sammenlignbart stort grunnlag av produksjonsbrukere, og den lengre historien i markedet betyr at det finnes et større utvalg av fellesskapsmoduler og mer gjennomprøvde providere i dag enn for noe enkelt alternativ, Pulumi inkludert.
Fordeler og ulemper: Terraform mot Pulumi
Terraform: fordeler
- Et etablert og mye større modulbibliotek gjennom Terraform Registry, bygget opp over nesten ti år.
- Et rent, formålsbygget konfigurasjonsspråk som er lett å lese for team med drift- og infrastrukturbakgrunn.
- Langt flere ressurser i markedet, med 18,3 % bruksandel i 2026 mot Pulumis 2,0 %, noe som gjør det lettere å finne erfarne folk og klare svar på vanlige problemer.
- OpenTofu finnes som et fullverdig, lisensfritt alternativ hvis Business Source License blir et problem internt.
- HCP Terraforms gratisnivå dekker opptil 500 forvaltede ressurser, nok for mange mindre prosjekter.
Terraform: ulemper
- Kjernen er ikke lenger åpen kildekode i vanlig forstand, siden Business Source License 1.1 trådte i kraft fra versjon 1.6.
- Hemmeligheter krypteres ikke i tilstandsfilen som standard, og krever HCP Terraform eller en separat Vault-integrasjon for å løse.
- HCL begrenser bevisst abstraksjon og gjenbruk, uten klasser og med kun begrenset kjøretidslogikk.
- Ingen innebygd programmerbart API tilsvarende Automation API for å bygge egne plattformer.
- Eksisterende brukere gir verktøyet en lavere admired-score (45,7 %) enn den lisensfrie forken OpenTofu (61,1 %).
Pulumi: fordeler
- Infrastrukturkoden skrives i et generelt programmeringsspråk teamet allerede kjenner, med vanlige løkker, klasser, pakkehåndtering og IDE-støtte.
- Kjernen (CLI og SDK) er åpen kildekode under Apache License 2.0, uten lisensbegrensninger.
- Hemmeligheter krypteres i transitt og i ro som standard, med egen nøkkel per stack og pluggbar KMS.
- Automation API gjør det mulig å bygge egne plattformer, noe som ligger bak resultatene hos Starburst, Wiz og BMW.
- Kan lese og kjøre eksisterende Terraform- og OpenTofu-konfigurasjoner direkte, uten tvungen omskriving.
Pulumi: ulemper
- Langt lavere bruksandel, 2,0 % mot Terraforms 18,3 % i 2026, noe som betyr færre erfarne utviklere å rekruttere og mindre fellesskapshjelp på nett.
- Et mindre modulbibliotek enn Terraform Registry, selv om eksisterende Terraform-providere kan adapteres.
- Prismodellen med Pulumi Credits fordelt over flere produkter (IaC-ressurser, Deployments, ESC, Neo) kan være vanskeligere å budsjettere nøyaktig enn en ren ressurstelling.
- Et generelt programmeringsspråk krever mer disiplin for å unngå overdreven abstraksjon i infrastrukturkoden, noe HCLs begrensninger faktisk forhindrer av seg selv.
- Opplæringskostnaden kan være høyere for rene driftsteam uten eksisterende programmeringserfaring.
Slik migrerer du fra Terraform til Pulumi
En fullstendig omskriving over natten er sjelden en god idé for infrastrukturkode som allerede kjører i produksjon. Begge leverandørene har derfor bygget stegvise veier som lar deg bevege deg gradvis, og du kan stoppe på hvilket som helst steg hvis det løser nok av problemet ditt.
- Steg 1: Flytt tilstanden først. Pek den eksisterende Terraform- eller OpenTofu-CLI-en mot Pulumi Cloud som ekstern backend. Fordi Pulumi Cloud implementerer Terraforms eksterne backend-API, fortsetter du å kjøre
terraform planogterraform applysom før, men får kryptert tilstand, versjonshistorikk, låsing, rollebasert tilgang og revisjonslogg på toppen, uten å endre en konfigurasjonsfil. - Steg 2: Vurder Pulumi HCL. Sett
runtime: hcliPulumi.yamlfor å kjøre de eksisterende.tf-filene direkte på Pulumis motor, med et kort dokumentert unntak av kanttilfeller. Dette gir tilgang til Pulumis øvrige plattform uten noen omskriving av selve koden. - Steg 3: Importer ressurser gradvis. Bruk
pulumi importog generert kode for å flytte enkeltressurser over til innfødte Pulumi-programmer, en komponent om gangen, i stedet for å forsøke alt samtidig. - Steg 4: Gjenbruk eksisterende moduler. Konsumer eksisterende Terraform-moduler direkte fra et Pulumi-program i et annet språk med kommandoen for å legge til en HCL-modul som pakke, slik at eksisterende investeringer ikke går til spille.
- Steg 5: Flytt hemmeligheter til kryptert konfigurasjon. Erstatt backend-avhengig state-kryptering med Pulumis standardkryptering per stack, og koble på en pluggbar KMS-tjeneste for sentral nøkkelhåndtering.
- Steg 6: Skriv tester i målspråket. Dekk ny Pulumi-kode med enhetstester i det valgte språkets eget rammeverk, mens eldre
terraform test-filer fortsatt kjører for delene som ikke er migrert ennå. - Steg 7: Ta i bruk Pulumi Deployments. Etter at tilstanden er flyttet, aktiver Git-drevne kjøringer, gjennomgang av pull request-stabler og automatisk driftdeteksjon for å få full nytte av plattformen.
Ingen av disse stegene krever at du fullfører de neste. Mange team stopper bevisst på steg 1 eller 2 i flere år, og får likevel kryptert tilstand og bedre styring uten noen omskriving. Les mer om hvordan du bygger infrastruktur som kode fra grunnen i vår guide til Terraform for AWS, som fortsatt er relevant uansett hvilken retning du til slutt velger.
Hvem bør velge hva: seks konkrete brukstilfeller
- Store virksomheter med eksisterende Terraform-moduler og HashiCorp-kompetanse i teamet bør som regel holde seg på Terraform eller HCP Terraform, og heller vurdere OpenTofu hvis lisensen er et reelt problem internt.
- Plattformteam som bygger interne utviklerportaler eller SaaS-produkter med behov for en programmerbar SDK, bør se til Pulumis Automation API, samme tilnærming som ligger bak resultatene hos Wiz og Starburst.
- Team i regulerte sektorer som bank, forsikring eller offentlig sektor, der kryptering av hemmeligheter i hviletilstand ofte er et revisjonskrav, får dette dekket uten tilleggsoppsett med Pulumis standardkryptering og pluggbare KMS-støtte.
- Utviklingsteam som allerede koder i Python, TypeScript eller Go til daglig, og som vil unngå å lære en ny domenespesifikk syntaks for infrastruktur, får raskere onboarding med Pulumi.
- Team som vil migrere gradvis uten stor omskriving, bør begynne med å flytte Terraform- eller OpenTofu-tilstanden til Pulumi Cloud som backend, og ta resten av stegene i eget tempo.
- Driftstunge team uten egen programmeringsbakgrunn, som verdsetter at HCL bevisst begrenser abstraksjon og kompleksitet, vil ofte finne Terraforms enklere mentale modell tryggere å drifte over tid.
Legg merke til at ingen av disse rådene er absolutte. Flere team i Norden kjører i praksis begge verktøyene side om side i dag, med Terraform for den etablerte kjerneinfrastrukturen og Pulumi for nyere, mer dynamiske plattformtjenester, akkurat fordi Pulumi Cloud lar dem håndtere begge deler i samme styringsplan.
Verdikt: hva sier dataene om 2026
For de fleste team er Terraform fortsatt det tryggeste standardvalget i 2026. Det brukes av 18,3 % av respondentene i Stack Overflows undersøkelse, mot Pulumis 2,0 %, og har et langt større bibliotek av ferdige moduler gjennom Terraform Registry. Hvis teamet allerede har HCL-kompetanse og et fungerende oppsett, er det sjelden grunn til å kaste alt og starte på nytt.
Men dataene peker også på noe annet: vekstraten og ikke bare det absolutte nivået. Pulumis bruksandel har mer enn firedoblet seg fra 0,48 % til 2,0 % siden 2023, og eksisterende Terraform-brukeres egen tilfredshet ligger bak den lisensfrie forken OpenTofus 61,1 % admired-score, mot Terraforms 45,7 %. Kombinert med dokumenterte resultater som Starburst sin 112 gangers kutt i utrullingstid og Wiz sin forvaltning av over én million skyressurser gjennom en programmerbar SDK, er konklusjonen tydelig: for team med behov for en programmerbar plattform, standard kryptering av hemmeligheter, eller som allerede koder i Python, Go eller TypeScript, kan Pulumi gi en reell og målbar fordel som Terraform ikke tilbyr i dag.
Den beste strategien for de fleste nordiske team i 2026 er derfor ikke et absolutt valg, men å teste Pulumi Cloud som state-backend for eksisterende Terraform-kode først, uten risiko for det som allerede kjører, og la konkrete resultater fra eget miljø avgjøre om en fullstendig overgang er verdt det. Se gjerne også vår sammenligning av EKS mot AKS mot GKE hvis infrastrukturvalget ditt også involverer hvilken administrert Kubernetes-tjeneste du bygger på.
Det ene tallet som er lettest å overse, men som kanskje betyr mest på lang sikt, er admired-forskjellen mellom Terraform og dets egen lisensfrie fork. Når 61,1 % av eksisterende OpenTofu-brukere ønsker å fortsette å bruke verktøyet, mot 45,7 % for Terraform selv, tyder det på en viss frustrasjon med nettopp de begrensningene denne artikkelen har pekt på: lisensvilkårene, kryptering av hemmeligheter som ikke er på som standard, og mangelen på et programmerbart API. Enten svaret for ditt team blir OpenTofu, Pulumi, eller en kombinasjon av begge med Terraform, er selve signalet verdt å ta med seg inn i 2027-budsjettet: status quo er ikke risikofritt bare fordi det er mest brukt.
Ofte stilte spørsmål om Terraform og Pulumi
Er Pulumi gratis å bruke?
Pulumi CLI og SDK-ene er åpen kildekode under Apache License 2.0 og helt gratis å bruke uten binding. Pulumi Clouds gratisutgave inkluderer dessuten forvaltet tilstand uten ekstra kostnad. Betalte utgaver legger til samarbeid for flere brukere, rollebasert tilgang, revisjonslogger og flere Pulumi Credits for Deployments, ESC og Neo.
Er Terraform fortsatt åpen kildekode?
Nei, ikke i vanlig forstand. Siden versjon 1.6 distribueres Terraform CLI under Business Source License 1.1, en lisens som begrenser kommersiell bruk av koden for konkurrenter. Dette var den direkte årsaken til at OpenTofu ble opprettet som en fullstendig åpen kildekode-fork under MPL-2.0-lisensen, nå forvaltet av Linux Foundation.
Kan jeg bruke eksisterende Terraform-moduler i Pulumi?
Ja. Pulumi-programmer i hvilket som helst støttet språk kan konsumere eksisterende Terraform-moduler som en pakke, og eksisterende Terraform-providere kan adapteres til Pulumi-providere. Du behøver derfor ikke kaste investeringen i eksisterende moduler bare fordi du bytter plattform.
Hva dekker HCP Terraforms gratisplan i 2026?
Gratisplanen dekker opptil 500 forvaltede ressurser per organisasjon under den nye Resources Under Management-modellen. Den gamle, brukerbaserte gratisplanen ble pensjonert 31. mars 2026, og alle eksisterende organisasjoner ble automatisk flyttet over til den ressursbaserte modellen.
Hvilke programmeringsspråk støtter Pulumi?
Pulumi støtter Python, TypeScript, JavaScript, Go, .NET, Java og YAML, samt HCL for team som vil beholde eksisterende Terraform-syntaks mens de flytter til Pulumis motor og plattform.
Kan jeg migrere gradvis fra Terraform til Pulumi uten full omskriving?
Ja. Den vanligste veien er å flytte tilstanden til Pulumi Cloud som ekstern backend først, siden den fortsatt forstår Terraforms backend-API. Deretter kan ressurser importeres gradvis med pulumi import, en komponent om gangen, uten å stoppe produksjonsmiljøer som allerede fungerer.
Hvem bruker Pulumi i produksjon i stor skala?
Dokumenterte eksempler inkluderer Starburst, som kuttet utrullingstiden for flerregions Kubernetes-distribusjoner fra to uker til rundt tre timer, Wiz, som forvalter over én million skyressurser gjennom Automation API, og BMWs Software Factory, som styrer over 20 000 skyressurser med Python-basert infrastrukturkode.
Er Pulumi mer populært enn Terraform i 2026?
Nei, ikke i absolutte tall. Terraform brukes av 18,3 % av respondentene i Stack Overflows 2026-undersøkelse, mot 2,0 % for Pulumi. Pulumis andel vokser imidlertid raskere relativt sett, fra 0,48 % i 2023 til dagens 2,0 %, mens Terraform gikk fra 11,3 % til 18,3 % i samme periode.
Hvilken av de to støtter flest skytjenester?
Begge har bred dekning, men løsningen er forskjellig. Pulumi Registry inneholder brodde, innfødte, parameteriserte og dynamiske providere, med skjema-genererte innfødte providere for blant annet Kubernetes, Azure Native, AWS Cloud Control og Google Cloud Native, og hvilken som helst eksisterende Terraform-provider kan adapteres til Pulumi. Terraform Registry dekker tilsvarende bredde gjennom HashiCorp- og fellesskapsforvaltede providere, bygget opp gjennom nesten ti år i markedet. I praksis finner de fleste team støtte for det de trenger hos begge, uansett om infrastrukturen kjører på AWS, Azure, Google Cloud eller en mindre nisjeleverandør.