# Pulumi vs Terraform 2026: Infrastructure as Code con TypeScript e Domande per Colloqui > Confronto Pulumi vs Terraform per il 2026. Supporto TypeScript, gestione dello state, ecosistemi di provider, strategie di migrazione e domande per colloqui DevOps. - Published: 2026-09-21 - Updated: 2026-09-21 - Author: Anthony Fillion-Maillet - Reading time: 5 min --- Pulumi vs Terraform rappresenta la decisione centrale sull'Infrastructure as Code per i team DevOps nel 2026. Entrambi gli strumenti provisionano risorse cloud in modo dichiarativo, ma differiscono nel supporto linguistico, nella gestione dello state e nella maturità dell'ecosistema. Questo confronto copre i compromessi tecnici, esempi di codice in TypeScript e HCL, e le domande da colloquio che emergono quando i candidati discutono scelte IaC. > **Contesto delle Versioni: Settembre 2026** > > Questo confronto utilizza Pulumi v3.263.0 (rilasciato il 15 settembre 2026) e Terraform 1.16.3 (rilasciato il 26 agosto 2026). CDKTF, il layer TypeScript di HashiCorp per Terraform, è stato deprecato a dicembre 2025 ed è archiviato. ## Architettura di Base: Engine di Pulumi vs Ciclo Plan-Apply di Terraform Terraform utilizza un linguaggio specifico di dominio (HCL) e un workflow a due fasi: `terraform plan` genera un piano di esecuzione, `terraform apply` lo esegue. Il file di state traccia i metadati delle risorse e viene memorizzato localmente o in backend remoti come S3 o Terraform Cloud. Pulumi incorpora il suo engine in runtime general-purpose. I programmi scritti in TypeScript, Python, Go o C# vengono eseguiti direttamente contro le API cloud attraverso i provider di Pulumi. Lo state viene memorizzato in Pulumi Cloud per default, con opzioni per backend autogestiti inclusi S3, Azure Blob Storage e file locali. La differenza architetturale si manifesta immediatamente nel modo in cui ogni strumento gestisce cicli, condizionali e astrazioni. Il `for_each` e `count` di Terraform operano entro i vincoli di HCL. I programmi Pulumi utilizzano costrutti nativi del linguaggio: `for...of` in TypeScript, list comprehension in Python, `range` in Go. ```typescript // infra/index.ts - Pulumi TypeScript example import * as aws from "@pulumi/aws"; import * as pulumi from "@pulumi/pulumi"; // Native TypeScript array methods work directly const environments = ["dev", "staging", "prod"]; const buckets = environments.map(env => new aws.s3.BucketV2(`data-${env}`, { bucket: `myapp-data-${env}-${pulumi.getStack()}`, tags: { Environment: env, ManagedBy: "pulumi", }, }) ); // Export bucket ARNs as stack outputs export const bucketArns = buckets.map(b => b.arn); ``` La configurazione Terraform equivalente richiede la sintassi HCL per l'iterazione: ```hcl # main.tf - Terraform HCL example variable "environments" { type = list(string) default = ["dev", "staging", "prod"] } resource "aws_s3_bucket" "data" { for_each = toset(var.environments) bucket = "myapp-data-${each.key}-${terraform.workspace}" tags = { Environment = each.key ManagedBy = "terraform" } } output "bucket_arns" { value = [for b in aws_s3_bucket.data : b.arn] } ``` Entrambi gli snippet creano tre bucket S3. La versione Terraform è concisa e leggibile per chiunque abbia familiarità con HCL. La versione Pulumi utilizza TypeScript standard, il che significa autocompletamento IDE, type checking e integrazione con codebase esistenti senza imparare un nuovo linguaggio. ## Supporto TypeScript: Linguaggio Nativo vs CDKTF (Deprecato) Pulumi ha supportato TypeScript fin dalla sua prima release pubblica. L'SDK espone classi di risorse tipizzate, e `pulumi.Output` avvolge valori asincroni che si risolvono durante il deployment. Strumenti di refactoring, linter e framework di test dall'ecosistema TypeScript si applicano direttamente. La risposta di Terraform al supporto di linguaggi general-purpose era [CDKTF (Cloud Development Kit for Terraform)](https://developer.hashicorp.com/terraform/cdktf). CDKTF permetteva ai team di scrivere TypeScript o Python che si compilava in Terraform JSON. HashiCorp ha deprecato CDKTF a dicembre 2025 e archiviato il repository. I progetti CDKTF esistenti continuano a funzionare, ma non vengono rilasciati aggiornamenti per nuove versioni di Terraform o modifiche dei provider. Per i team che vogliono TypeScript IaC nel 2026, Pulumi è l'opzione mantenuta attivamente. I team già investiti in CDKTF possono continuare a eseguire i loro stack, ma la migrazione a HCL o Pulumi è la strada da seguire per nuovi sviluppi. ```typescript // infra/vpc.ts - Pulumi component for reusable VPC abstraction import * as aws from "@pulumi/aws"; import * as pulumi from "@pulumi/pulumi"; // Custom component encapsulating VPC, subnets, and routing export class StandardVpc extends pulumi.ComponentResource { public readonly vpcId: pulumi.Output; public readonly publicSubnetIds: pulumi.Output[]; constructor(name: string, args: { cidr: string; azCount: number }, opts?: pulumi.ComponentResourceOptions) { super("mycompany:network:StandardVpc", name, {}, opts); const vpc = new aws.ec2.Vpc(`${name}-vpc`, { cidrBlock: args.cidr, enableDnsHostnames: true, tags: { Name: name }, }, { parent: this }); this.vpcId = vpc.id; // Create public subnets across availability zones const azs = aws.getAvailabilityZones({ state: "available" }); this.publicSubnetIds = []; for (let i = 0; i < args.azCount; i++) { const subnet = new aws.ec2.Subnet(`${name}-public-${i}`, { vpcId: vpc.id, cidrBlock: `10.0.${i}.0/24`, availabilityZone: azs.then(az => az.names[i]), mapPublicIpOnLaunch: true, tags: { Name: `${name}-public-${i}` }, }, { parent: this }); this.publicSubnetIds.push(subnet.id); } this.registerOutputs({ vpcId: this.vpcId }); } } ``` Questo componente Pulumi crea un'astrazione VPC riutilizzabile. I consumatori lo istanziano con `new StandardVpc("prod", { cidr: "10.0.0.0/16", azCount: 3 })`. L'equivalente in Terraform è una directory di modulo con variabili, output e file HCL. Entrambi gli approcci abilitano il riuso; la versione Pulumi eredita il tooling di TypeScript per documentazione, testing e versionamento. ## Gestione dello State e Opzioni Backend La gestione dello state è dove emergono le differenze operative. Lo state di Terraform contiene ID delle risorse, metadati del provider e valori sensibili. I team devono configurare backend remoti per abilitare la collaborazione e implementare il locking per prevenire modifiche concorrenti. [La configurazione del backend Terraform](https://developer.hashicorp.com/terraform/language/settings/backends/configuration) supporta S3, Azure Blob, Google Cloud Storage, Terraform Cloud e altri. Ogni backend richiede la propria configurazione di autenticazione. Il locking dello state utilizza DynamoDB per backend S3, blob lease per Azure, o locking nativo in Terraform Cloud. Pulumi Cloud gestisce memorizzazione dello state, locking e cronologia per default. I team creano un account gratuito, eseguono `pulumi login`, e la gestione dello state è configurata. Per i team che richiedono state autogestito, Pulumi supporta backend S3, Azure Blob, GCS e file locali con il comando `pulumi login`. ```bash # Pulumi: login to self-managed S3 backend pulumi login s3://my-pulumi-state-bucket # Terraform: configure S3 backend in HCL # backend.tf terraform { backend "s3" { bucket = "my-terraform-state" key = "prod/terraform.tfstate" region = "us-east-1" dynamodb_table = "terraform-locks" encrypt = true } } ``` Pulumi Cloud fornisce una UI web per cronologia degli stack, visualizzazione delle risorse e permessi del team. Terraform Cloud offre funzionalità simili con policy enforcement attraverso Sentinel. Opzioni self-hosted esistono per entrambi: backend self-hosted di Pulumi e Terraform Enterprise. ## Ecosistema dei Provider e Supporto Multi-Cloud L'ecosistema di provider Terraform è il più grande nell'IaC. Il [Terraform Registry](https://registry.terraform.io/) elenca oltre 4.000 provider che coprono AWS, Azure, GCP, Kubernetes e centinaia di piattaforme SaaS. La qualità dei provider varia: i provider ufficiali HashiCorp e dei vendor cloud ricevono aggiornamenti regolari, mentre i provider della community potrebbero restare indietro rispetto ai cambiamenti delle API. I provider Pulumi avvolgono i provider Terraform usando un bridge che genera SDK tipizzati. Il [Pulumi Registry](https://www.pulumi.com/registry/) espone provider per i principali cloud, Kubernetes, database e servizi di monitoraggio. Poiché Pulumi fa bridge dei provider Terraform, la copertura dell'ecosistema è comparabile, sebbene le nuove versioni dei provider Terraform richiedano aggiornamenti del bridge prima che gli SDK Pulumi riflettano i cambiamenti. Pulumi offre anche provider nativi scritti direttamente contro le API cloud. I provider nativi per AWS, Azure e Kubernetes forniscono supporto same-day per nuove funzionalità API. Il compromesso è che i provider nativi esistono solo per i cloud principali; i servizi meno comuni usano provider bridged. ```typescript // Using Pulumi's native AWS provider for Lambda import * as aws from "@pulumi/aws"; import * as pulumi from "@pulumi/pulumi"; const role = new aws.iam.Role("lambda-role", { assumeRolePolicy: aws.iam.assumeRolePolicyForPrincipal({ Service: "lambda.amazonaws.com", }), }); const lambdaFunction = new aws.lambda.Function("api-handler", { runtime: aws.lambda.Runtime.NodeJS20dX, handler: "index.handler", role: role.arn, code: new pulumi.asset.AssetArchive({ "index.js": new pulumi.asset.StringAsset( `exports.handler = async () => ({ statusCode: 200, body: "OK" });` ), }), }); export const functionArn = lambdaFunction.arn; ``` ## Testing del Codice Infrastrutturale Il testing è dove la scelta del linguaggio crea divergenza. I programmi Pulumi sono codice standard, quindi gli unit test usano framework familiari. Il modulo `@pulumi/pulumi/runtime` fornisce mocking per la creazione di risorse, permettendo ai test di verificare la configurazione senza deployare risorse. ```typescript // __tests__/infra.test.ts - Unit testing Pulumi resources with Vitest import { describe, it, expect, beforeAll } from "vitest"; import * as pulumi from "@pulumi/pulumi"; // Mock Pulumi runtime pulumi.runtime.setMocks({ newResource: (args: pulumi.runtime.MockResourceArgs) => { return { id: `${args.name}-id`, state: args.inputs }; }, call: (args: pulumi.runtime.MockCallArgs) => { return args.inputs; }, }); describe("S3 Bucket Configuration", () => { let bucketTags: Record; beforeAll(async () => { // Import the Pulumi program after mocks are set const infra = await import("../infra/index"); // Extract outputs for testing bucketTags = await new Promise(resolve => { infra.buckets[0].tags.apply(tags => resolve(tags as Record)); }); }); it("should tag buckets with Environment", () => { expect(bucketTags).toHaveProperty("Environment"); }); it("should tag buckets with ManagedBy", () => { expect(bucketTags.ManagedBy).toBe("pulumi"); }); }); ``` Il testing Terraform usa `terraform test` (introdotto in Terraform 1.6) o strumenti esterni come Terratest. `terraform test` esegue file di test HCL che creano risorse reali in configurazioni isolate. Terratest è una libreria Go che avvolge i comandi Terraform e fornisce assertion. ```hcl # tests/bucket.tftest.hcl - Terraform native test run "bucket_tags" { command = plan assert { condition = aws_s3_bucket.data["dev"].tags["Environment"] == "dev" error_message = "Bucket must be tagged with Environment" } assert { condition = aws_s3_bucket.data["dev"].tags["ManagedBy"] == "terraform" error_message = "Bucket must be tagged with ManagedBy" } } ``` Entrambi gli approcci validano la configurazione dell'infrastruttura. Il vantaggio di Pulumi è l'integrazione con test runner TypeScript e strumenti di coverage. I test nativi di Terraform funzionano senza dipendenze esterne ma richiedono sintassi HCL. ## Domande per Colloqui: Pulumi vs Terraform I colloqui DevOps nel 2026 includono frequentemente confronti di strumenti IaC. Ecco domande che distinguono i candidati che hanno usato entrambi gli strumenti in produzione. **"Cosa succede quando lo state Terraform diverge dall'infrastruttura reale?"** Risposta attesa: `terraform plan` rileva il drift confrontando lo state con l'infrastruttura reale. Il piano mostra le risorse da aggiornare, creare o distruggere. Il drift si verifica quando vengono apportate modifiche al di fuori di Terraform (console, CLI, altri strumenti). Le opzioni includono `terraform refresh` per aggiornare lo state, `terraform import` per portare le risorse sotto gestione, o accettare il piano per ripristinare lo stato desiderato. **"Come gestisce Pulumi i secret in modo diverso da Terraform?"** Risposta attesa: Pulumi cripta i secret nello state per default usando una passphrase o cloud KMS. La funzione `pulumi.secret()` marca i valori come sensibili, e rimangono criptati at rest. Terraform memorizza i secret in plaintext nei file di state; i team si affidano alla crittografia del backend (crittografia server-side S3) e ai controlli di accesso. Terraform 1.4 ha aggiunto il marking delle variabili `sensitive`, ma i valori appaiono comunque non criptati nello state. **"Perché HashiCorp ha deprecato CDKTF, e quali sono le opzioni di migrazione?"** Risposta attesa: CDKTF aggiungeva overhead di manutenzione senza corrispondere alla cadenza di aggiornamento di Terraform. Nuove versioni dei provider e funzionalità Terraform richiedevano aggiornamenti manuali ai binding CDK. HashiCorp ha scelto di concentrarsi su HCL e Terraform Cloud. Le opzioni di migrazione sono: convertire a HCL usando `cdktf convert`, riscrivere in Pulumi se TypeScript è richiesto, o continuare a eseguire stack CDKTF esistenti senza aggiornamenti. **"Quando sceglieresti Pulumi rispetto a Terraform per un nuovo progetto?"** Risposta attesa: Scegliere Pulumi quando il team usa già TypeScript/Python/Go e vuole IaC nello stesso linguaggio del codice applicativo, quando astrazioni complesse richiedono costrutti di programmazione reali (generics, interfacce, framework di test), o quando la crittografia dei secret integrata è un requisito. Scegliere Terraform quando il team conosce HCL, quando l'ecosistema dei provider deve includere provider di nicchia o della community, o quando il tooling organizzativo (Atlantis, Spacelift) si integra con Terraform. ## Strategie di Migrazione: da Terraform a Pulumi Pulumi fornisce `pulumi import` per portare risorse cloud esistenti sotto gestione senza ricrearle. Per i team con state Terraform, `pulumi convert` traduce HCL in programmi Pulumi. La conversione non è perfetta: moduli complessi e blocchi dinamici richiedono aggiustamenti manuali. ```bash # Convert Terraform HCL to Pulumi TypeScript pulumi convert --from terraform --language typescript # Import existing AWS resources into Pulumi state pulumi import aws:s3/bucketV2:BucketV2 my-bucket my-existing-bucket-name ``` Una migrazione graduale permette ai team di eseguire entrambi gli strumenti durante la transizione. Terraform gestisce gli stack esistenti mentre Pulumi provisiona nuova infrastruttura. Una volta che i team acquisiscono esperienza con Pulumi, convertono gli stack Terraform in modo incrementale. Lo state non è condiviso tra gli strumenti, quindi la gestione delle risorse deve essere chiaramente divisa per evitare conflitti. ## Framework Decisionale per il 2026 | Fattore | Terraform | Pulumi | |---------|-----------|--------| | Linguaggio | HCL (DSL) | TypeScript, Python, Go, C#, Java, YAML | | Gestione state | Autogestito o Terraform Cloud | Pulumi Cloud (default) o autogestito | | Gestione secret | Plaintext nello state, crittografia backend | Criptato per default | | Testing | `terraform test`, Terratest | Framework di test del linguaggio nativo | | Copertura provider | 4.000+ nel registry | Provider Terraform bridged + SDK nativi | | Supporto TypeScript | CDKTF (deprecato dicembre 2025) | First-class, mantenuto attivamente | | Curva di apprendimento | HCL è purpose-built, rapido per IaC | Richiede conoscenza linguistica esistente | | Funzionalità enterprise | Terraform Cloud/Enterprise | Pulumi Cloud/self-hosted | > **Suggerimento per il Colloquio** > > Quando viene chiesto di Pulumi vs Terraform, evitare di dire che uno sia "migliore". Articolare i compromessi: Terraform ha un ecosistema più ampio e i vincoli di HCL prevengono errori runtime; Pulumi offre funzionalità del linguaggio reali e SDK tipizzati. Dimostrare che la scelta dipende dalle competenze del team, dal tooling esistente e dai requisiti del progetto. ## Punti Chiave per Infrastructure as Code nel 2026 - Terraform 1.16 è la scelta stabile per IaC basato su HCL con il più grande ecosistema di provider e tooling maturo (Atlantis, Spacelift, env0). - Pulumi v3.263 offre TypeScript, Python, Go e C# con testing nativo del linguaggio, integrazione IDE e crittografia dei secret integrata. - CDKTF è deprecato da dicembre 2025. I team che vogliono TypeScript IaC dovrebbero valutare Pulumi piuttosto che iniziare nuovi progetti CDKTF. - Entrambi gli strumenti supportano deployment multi-cloud, backend di state remoti e collaborazione di team. La scelta dipende dalla preferenza linguistica e dall'expertise esistente del team. - Le discussioni nei colloqui dovrebbero dimostrare comprensione della gestione dello state, rilevamento del drift, ecosistemi dei provider e i compromessi tra semplicità DSL e potenza del linguaggio general-purpose. - La migrazione da Terraform a Pulumi è possibile usando `pulumi convert` e `pulumi import`, ma richiede pianificazione attenta e rollout graduale. --- Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack. HTML version of this page: https://sharpskill.dev/it/blog/devops/pulumi-vs-terraform-2026-infrastructure-as-code-typescript-interview-questions