OpenTofu Spiegato: Il Fork di Terraform, la Migrazione e Se Conviene Passare

Apri oggi un modulo Terraform e ti troverai davanti a una domanda che non esisteva tre anni fa: il binario che esegue questo codice è terraform, oppure è tofu? IBM ha completato la sua acquisizione di HashiCorp il 27 febbraio 2025, per 6,4 miliardi di dollari, e OpenTofu è diventato un progetto CNCF Sandbox il 23 aprile 2025, e il percorso di migrazione tra i due strumenti è ora documentato ufficialmente. La decisione non è più ipotetica.

Questo articolo è scritto dal punto di vista delle operazioni infrastrutturali, non dal punto di vista di una piattaforma Terraform gestita. L'obiettivo è separare i costi reali della migrazione dal rumore su licenze e governance. Questo significa poter essere diretto su cosa si rompe durante la migrazione, sulle legittime questioni di governance e sui casi in cui restare su Terraform è la scelta giusta.

Questo articolo copre quattro aspetti: cos'è OpenTofu nel 2026, le funzionalità che Terraform non ha, come si presenta la migrazione nella pratica e una raccomandazione chiara per gli scenari decisionali più comuni.

La versione breve

• OpenTofu è un fork open source di Terraform, con licenza MPL 2.0, ospitato dalla Linux Foundation ed è un progetto CNCF Sandbox dal 23 aprile 2025. È nato come fork di Terraform 1.5.x dopo che HashiCorp ha spostato Terraform sulla Business Source License nell'agosto 2023.
• Al 26 luglio 2026, la release di manutenzione attuale è v1.12.5; il repository su GitHub ha più di 29.000 stelle, e il sito ufficiale del progetto OpenTofu elenca oltre 3.900 provider e oltre 23.600 moduli.
• Offre funzionalità esclusive di OpenTofu o in cui OpenTofu è all'avanguardia, che Terraform al momento non eguaglia allo stesso modo: crittografia lato client di state e plan, provider for_each, valutazione anticipata delle variabili, il enabled meta-argomento e dinamico prevent_destroy. Le risorse effimere non sono esclusive di OpenTofu; Terraform le supporta dalla versione 1.10.
• Per un piccolo progetto Terraform 1.5.x con state locale o su S3, il percorso ideale può essere una migrazione breve e reversibile. I riferimenti CI/CD, i workflow specifici di HCP e le modifiche al dependency-lock sono dove il lavoro si espande.
• Per un nuovo progetto IaC nel 2026, inizia con OpenTofu. Per un'implementazione Terraform già esistente, passa quando la BSL diventa un problema concreto, quando ti serve una funzionalità che OpenTofu ha e Terraform no, o quando la roadmap controllata da IBM è una preoccupazione reale. Altrimenti il rapporto costi-benefici è debole.

Cos'è OpenTofu nel 2026

OpenTofu è un fork open source di Terraform, ospitato dalla Linux Foundation, accettato nella CNCF come progetto Sandbox il 23 aprile 2025 e distribuito con licenza Mozilla Public License 2.0. Il binario è tofu. Il linguaggio di configurazione è HCL, lo stesso usato da Terraform. Per la maggior parte dei progetti da semplici a medi, una codebase Terraform esistente funziona senza modifiche su OpenTofu.

Il fork è iniziato nell'agosto 2023, dopo che HashiCorp ha spostato Terraform dalla MPL 2.0 alla Business Source License 1.1 il 10 agosto 2023. La BSL è source-available anziché approvata dall'OSI e limita l'uso in produzione che "compete con le offerte commerciali di HashiCorp". Entro cinque giorni è stato pubblicato l'OpenTF Manifesto ed è stato annunciato un fork. L'annuncio della Linux Foundation ha presentato ufficialmente OpenTofu il 20 settembre 2023.

L'annuncio della Linux Foundation ha citato Harness, Gruntwork, Spacelift, env0, Scalr, Digger, Terrateam, Massdriver e Terramate tra i sostenitori fondatori, con almeno 18 ingegneri impegnati a tempo pieno per un minimo di cinque anni. OpenTofu è nato come fork di Terraform 1.5.x, l'ultima versione con licenza MPL 2.0.

A che punto è oggi il progetto: v1.12.5 è la release di manutenzione attuale, e il sito ufficiale elenca oltre 3.900 provider e oltre 23.600 moduli. I segnali di adozione non si limitano più allo slancio iniziale di un fork di protesta: uno caso di studio sulla migrazione di Fidelity descrive un programma che copre oltre 50.000 file di state e quattro milioni di risorse.

Il contesto aziendale rilevante: IBM ha completato l'acquisizione di HashiCorp il 27 febbraio 2025, per 6,4 miliardi di dollari. La roadmap di Terraform è ora definita all'interno di un fornitore enterprise molto più grande. Questo non è automaticamente un bene o un male per gli utenti, ma fa parte del calcolo che i team stanno facendo nel 2026.

In Cosa OpenTofu Differisce da Terraform

Dal momento del fork, i due progetti hanno seguito percorsi di funzionalità diversi. La tabella sottostante è la versione breve; le note che seguono spiegano cosa cambia ogni differenza per chi lavora sul campo.

Lato client crittografia dello state (v1.7.0, 30 aprile 2024). OpenTofu può crittografare i file di state e plan direttamente nello strumento con PBKDF2, AWS KMS, GCP KMS o OpenBao. Terraform in genere delega la crittografia a riposo al backend selezionato, mentre lo state locale resta in chiaro. La crittografia lato client di OpenTofu può proteggere un oggetto state rubato o un plan in cache, a condizione che la chiave di decrittazione non venga esposta insieme ad esso. Non sostituisce TLS, i controlli di accesso del backend o la disciplina di gestione dei segreti.

La configurazione ha più o meno questo aspetto:

terraform {
  encryption {
    key_provider "pbkdf2" "passphrase" {
      passphrase = var.tofu_state_passphrase
    }
    method "aes_gcm" "default" {
      keys = key_provider.pbkdf2.passphrase
    }
    state {
      method = method.aes_gcm.default
    }
  }
}

Fornitore for_each (v1.9). Puoi iterare le configurazioni dei provider allo stesso modo in cui iteri le risorse. Per configurazioni multi-regione o multi-account, questo elimina un'intera classe di soluzioni alternative di lunga data. Non devi più scrivere a mano un provider con alias per ogni regione; puoi gestire tutto da un unico blocco basato su una map.

Valutazione anticipata delle variabili (v1.8). Le variabili possono ora essere referenziate in punti precedentemente vietati, inclusi gli argomenti di backend e module source. Questo è utile quando un unico modulo root gestisce più ambienti che differiscono solo per un piccolo insieme di variabili.

Le risorse effimere e il enabled meta-argomento (v1.11.0, 9 dicembre 2025). OpenTofu 1.11 ha aggiunto le risorse effimere e il enabled meta-argomento. Le risorse effimere esistono solo all'interno di un singolo ciclo plan/apply e non persistono nello state, il che è utile per credenziali di breve durata. Non sono esclusive di OpenTofu: Terraform le ha introdotte nella 1.10 e ha aggiunto argomenti write-only nella 1.11. La capacità specifica di OpenTofu qui è enabled, che attiva o disattiva un blocco resource in base a un'espressione senza bisogno di count acrobazie.

Dinamico prevent_destroy (v1.12). Di Terraform prevent_destroy accetta solo valori letterali. OpenTofu 1.12 permette di calcolarlo, così un unico modulo può mantenere lo staging distruggibile proteggendo al contempo la produzione.

La riga della licenza è la differenza strutturale che non si manifesta come funzionalità. MPL 2.0 è approvata dall'OSI ed è copyleft a livello di file. La licenza BSL 1.1 di Terraform è source-available, include una restrizione d'uso aggiuntiva e passa a MPL 2.0 quattro anni dopo la pubblicazione di ciascuna opera concessa in licenza. Per la maggior parte dei team l'effetto pratico è minimo; per i fornitori che costruiscono qualcosa di vicino alle offerte commerciali di HashiCorp, questo è il motivo per cui il fork esiste.

Migrazione: Cosa Si Rompe Davvero

La guida ufficiale alla migrazione è volutamente breve e reversibile: fai il backup di state e codice, installa OpenTofu, esegui tofu init, confronta tofu plane testa una piccola modifica. Le parti difficili non sono i comandi. Sono i riferimenti CI/CD circostanti, i workflow specifici di HCP, le modifiche al dependency-lock e la revisione organizzativa che accompagna l'adozione di un fork.

Il Percorso Semplice

Per un progetto che non usa HCP Terraform e non ha migliaia di riferimenti nelle pipeline a terraform, la migrazione è semplice.

# Back up state first, non-negotiable.
cp terraform.tfstate terraform.tfstate.bak

# Install OpenTofu (Linux example).
curl --proto '=https' --tlsv1.2 -fsSL \
  https://get.opentofu.org/install-opentofu.sh | sh -s -- --install-method standalone

# Re-initialize against the OpenTofu registry.
tofu init -upgrade

# Verify parity with what Terraform was doing.
tofu plan

tofu plan dovrebbe corrispondere al plan prodotto da Terraform. Se c'è un diff inatteso, controlla le versioni dei provider, le impostazioni del backend ed eventuali funzionalità di Terraform successive alla 1.5.x prima di applicare.

Ci sono due sfumature importanti prima di eseguire qualsiasi cosa. Primo, OpenTofu è ampiamente compatibile a livello di configurazione con l'HCL in stile Terraform per i casi descritti in questa guida, ma le funzionalità aggiunte dopo Terraform 1.5.x richiedono comunque un controllo di compatibilità. Secondo, tofu init -upgrade potrebbe aggiornare .terraform.lock.hcl, inclusi gli indirizzi source dei provider e le voci di checksum. Rivedi questi metadati separatamente dal drift dell'infrastruttura.

I Veri Ostacoli

Tre elementi possono trasformare una rapida migrazione via CLI in un progetto di piattaforma più ampio. Nessuno di essi è un bug.

Workspace di HCP Terraform. OpenTofu include integrazioni cloud e remote per servizi remote compatibili, incluso HCP Terraform negli scenari di esecuzione locale e archiviazione dello state. La parte più difficile è l'esecuzione remota specifica di HCP e le funzionalità di piattaforma: Sentinel, run trigger, credenziali dinamiche, Stacks, e qualsiasi comportamento del servizio che OpenTofu non può testare o supportare pienamente. Se questi elementi sono centrali, avvia prima un pilota su un singolo workspace; se stai abbandonando HCP, migra lo state e ricostruisci questi controlli di piattaforma.

Consiglio pratico: abbandonare HCP Terraform può essere il costo nascosto più grande quando l'infrastruttura dipende da workflow specifici di HCP. Prima di decidere, esegui terraform state pull > state.json e verifica la dimensione e il numero di risorse. Un workspace con 200 risorse è un progetto diverso da una flotta di 50 workspace con run trigger e policy set. Quest'ultimo caso è una migrazione di platform engineering, non una semplice sostituzione di strumento.

Pipeline CI/CD con riferimenti fissi a terraform. Ogni riferimento a terraform plan, terraform apply, il percorso del binario, l'immagine Docker e lo step GitHub Actions o GitLab CI va rivisto. Per GitHub Actions, la sostituzione è più o meno questa:

# Before
- name: Setup Terraform
  uses: hashicorp/setup-terraform@v3
  with:
    terraform_version: 1.5.7

- run: terraform init
- run: terraform plan

# After
- name: Setup OpenTofu
  uses: opentofu/setup-opentofu@v2
  with:
    tofu_version: 1.12.5

- run: tofu init
- run: tofu plan

Questo è il caso banale: un workflow, un repository. In un monorepo con composite action condivise, più pipeline e una libreria di workflow riutilizzabili, la superficie da rivedere è molto più ampia. Il lavoro è meccanico, ma può richiedere più tempo della semplice sostituzione della CLI.

Revisione del file di dependency lock. tofu init potrebbe aggiornare .terraform.lock.hcl, inclusi gli indirizzi source dei provider e le voci di checksum. OpenTofu 1.12 può anche aggiungere set completi di checksum h1: per tutte le piattaforme. Tratta il diff come metadati di dipendenza da rivedere e commitare separatamente, non come drift dell'infrastruttura.

Consiglio pratico: il diff del lock-file può sembrare disordinato al primo commit. Esegui tofu init -upgrade su un branch pulito, esegui il commit solo del file di lock con un messaggio chiaro come "review OpenTofu lock-file changes", quindi fai il rebase del lavoro sulla feature sopra di esso. Mescolare i metadati delle dipendenze in una PR di feature rende entrambe le modifiche più difficili da revisionare.

Resistenza degli stakeholder. "Ora usiamo un fork" viene recepito in modo diverso a seconda dell'organizzazione. La controargomentazione onesta è che OpenTofu resta ampiamente compatibile a livello di configurazione con l'HCL in stile Terraform per i casi descritti in questa guida, quindi il passaggio è di solito reversibile. Se OpenTofu sparisse domani, molti team potrebbero reinstallare Terraform, rivedere il lock file e continuare a usare gli stessi .tf file. Convalida prima le funzionalità post-fork; questa avvertenza è più credibile della promessa di una perfetta intercambiabilità.

Quando la Migrazione È Davvero Difficile

Questo percorso semplice non si applica a ogni infrastruttura Terraform.

La migrazione diventa nettamente più difficile quando:

• Lo state è di grandi dimensioni (migliaia di risorse, decine di workspace) e risiede in HCP Terraform.
• La codebase utilizza in profondità funzionalità esclusive di HCP: policy Sentinel collegate ai workspace, run trigger, credenziali dinamiche dei provider gestite da HCP. Terraform Stacks è esclusivo di HCP e non ha un equivalente in OpenTofu, il che esula da questo articolo.
• Un audit aziendale o un framework di compliance indica "Terraform" come lo strumento IaC ufficiale, il che rappresenta un problema di procurement e documentazione oltre a quello tecnico.
• Una grande libreria di moduli ha vincoli di versione interni che sono stati risolti in base al comportamento specifico del registry di Terraform.

Non tutti i team dovrebbero migrare. Il rapporto costi-benefici ha senso solo quando le restrizioni della BSL influenzano realmente il tuo caso d'uso, quando una funzionalità specifica di OpenTofu sblocca qualcosa di concreto, o quando una roadmap controllata da IBM è una preoccupazione reale per la tua organizzazione. Se nessuna di queste condizioni si applica, restare su Terraform è una scelta perfettamente difendibile.

Dovresti Passare a OpenTofu?

Qui non esiste un'unica risposta giusta. Quando disegno l'albero decisionale per un team, emergono quattro schemi comuni, e la mossa giusta dipende da quale schema ti rispecchia.

Nuova adozione IaC (greenfield). Inizia con OpenTofu. La licenza è MPL 2.0, la governance è sotto la Linux Foundation e la CNCF, e il progetto ha un ritmo di rilascio attivo. I suoi elementi distintivi includono la crittografia lato client dello state, provider for_each, enablede dinamico prevent_destroy. Non c'è alcun attrito legato alla BSL da considerare. Questo è il consiglio più forte di questo articolo.

Utente Terraform esistente, progetto piccolo o medio. Passa a OpenTofu se scatta anche solo uno dei tre fattori. Uno: vendi o potresti vendere un prodotto che potrebbe rientrare nella clausola "compete con HashiCorp" della BSL; il calcolo legale è più chiaro con MPL 2.0. Due: hai bisogno della crittografia lato client dello state, provider for_each, enabledo dinamico prevent_destroy e il workaround su Terraform non vale più la pena mantenerlo. Tre: preferisci una governance multi-parte a una roadmap controllata da un unico fornitore. Se nessuna di queste condizioni si applica e Terraform funziona senza problemi, resta dov'è. La migrazione è reversibile in molte infrastrutture, ma non è gratuita.

Utente intensivo di HCP Terraform. Considera questa una decisione di piattaforma, non automaticamente una migrazione del backend. OpenTofu può usare backend remote compatibili, ma l'esecuzione remota specifica di HCP, Sentinel, run trigger, credenziali dinamiche e Stacks richiedono comunque una valutazione funzionalità per funzionalità. Se questi controlli sono centrali, avvia prima un pilota. Se stai abbandonando HCP per motivi di licenza, costo o governance, pianifica il lavoro come una migrazione di piattaforma.

Stai valutando Pulumi o un'altra alternativa non basata su HCL. OpenTofu è il percorso più vicino se vuoi mantenere HCL e la maggior parte dei workflow esistenti. Pulumi è una scelta di piattaforma e linguaggio più ampia: TypeScript, Python, Go o .NET che pilotano le API cloud. Passare a Pulumi può comportare conversione o riscrittura, quindi valutalo separatamente da un semplice cambio di binario da Terraform a OpenTofu.

C'è un'altra cosa che vale la pena affrontare direttamente: la critica legittima secondo cui OpenTofu sarebbe in parte una copertura per i fornitori SaaS. Un thread su Hacker News sul cambio della BSL ha sollevato la preoccupazione che i membri fondatori del progetto siano piattaforme Terraform commerciali con un proprio interesse nella flessibilità di licenza. Prendo sul serio questa preoccupazione. L'elemento di mitigazione è la struttura di governance, l'hosting della Linux Foundation, il CNCF Sandbox, MPL 2.0 su ogni file, che rende una futura rilicenziazione molto più difficile di quanto lo sia stata una rilicenziazione da parte di un unico fornitore. Questo non la rende impossibile. Ma la rende abbastanza costosa da rappresentare un freno reale.

Verdetto rapido. Per un nuovo lavoro IaC nel 2026, inizia con OpenTofu. La sua licenza, la governance, lo sviluppo attivo e il set di funzionalità lo rendono una scelta predefinita solida. Per le implementazioni Terraform già esistenti, passa quando si applica uno dei tre fattori sopra indicati; altrimenti il rapporto costi-benefici è debole ed è del tutto ragionevole restare dov'è.

Una volta chiara la scelta dello strumento, la prossima domanda pratica è dove far girare OpenTofu. Questa decisione influisce sulla gestione dei secret, sui costi, sulla ripetibilità e su quanto controllo il tuo team ha sull'ambiente di esecuzione.

Eseguire OpenTofu in Autonomia

OpenTofu è un binario a riga di comando. Dove lo esegui determina molto in termini di costi, sicurezza e cosa puoi farci. Ci sono grosso modo tre luoghi sensati dove collocarlo.

Laptop o macchina di sviluppo. Va bene per plan occasionali, prototipazione e piccoli progetti personali. È una scelta predefinita scarsa per workflow di produzione condivisi, a meno che remote state, locking e disciplina di revisione non siano già applicati. I team traggono di solito beneficio da un ambiente di esecuzione canonico invece che da un laptop qualunque su cui è stato eseguito per ultimo tofu apply.

Runner CI gestito (GitHub Actions, GitLab CI, ecc.). Il percorso più comune. L'azione opentofu/setup-opentofu è un sostituto diretto per hashicorp/setup-terraform. Questo funziona bene per la maggior parte dei team e dei progetti. Compromessi: i secret transitano attraverso un servizio CI di terze parti, i minuti del piano gratuito possono esaurirsi con grandi operazioni di state, e l'ambiente del runner è effimero, il che di solito è un vantaggio ma a volte un limite. Vedi GitHub vs GitLab se stai ancora scegliendo tra opzioni CI ospitate, e Best CI/CD Tools per un quadro più ampio.

Runner self-hosted su un VPS. Utile quando i compromessi del CI gestito smettono di funzionare: i secret devono restare fuori da un servizio di terze parti, i minuti CI diventano costosi, oppure vuoi cache persistenti dei provider. La configurazione è semplice: un VPS Linux, il binario OpenTofu, un agente GitHub Actions o GitLab Runner, e Docker per l'isolamento dei job. Vedi Install Docker on VPS se questa parte è nuova per te. Per un runner di un piccolo team, 4 GB di RAM, 2 vCPU e 60 GB di NVMe sono un punto di partenza ragionevole; scala CPU, memoria e storage per plan più grandi e maggiore concorrenza.

Per i team che hanno bisogno di un controllo più stretto sui secret del runner, cache persistenti dei provider o costi CI prevedibili, un runner self-hosted su un VPS può avere senso. In questa configurazione, dai priorità all'accesso root, a uno storage NVMe veloce, alla facilità di ridimensionamento e a CPU/RAM sufficienti per operazioni di plan più grandi.

Cloudzy Linux VPS si adattano bene a questo schema di runner self-hosted, con accesso root, storage NVMe e dimensionamento flessibile, così puoi iniziare in piccolo e scalare il runner man mano che i tuoi carichi di lavoro OpenTofu crescono.

Domande frequenti

OpenTofu è la Stessa Cosa di Terraform?

Non esattamente. OpenTofu è nato come fork di Terraform 1.5.x e resta ampiamente compatibile a livello di configurazione con l'HCL in stile Terraform: gli stessi .tf file, provider e plan/apply workflow per molti progetti. Differiscono nella licenza e nelle funzionalità aggiunte dopo il fork. OpenTofu ha la crittografia lato client dello state, provider for_each, enablede dinamico prevent_destroy; Terraform ha le proprie funzionalità post-fork, incluse le risorse effimere.

OpenTofu Supporterà Tutti i Miei Provider Terraform?

Per i provider principali come AWS, GCP, Azure, Kubernetes e Helm, generalmente sì. Il OpenTofu Registry riporta oltre 3.900 provider a luglio 2026. tofu init potrebbe aggiornare .terraform.lock.hcl metadati. Per provider di nicchia, specifici di un fornitore o pubblicati di recente, verifica direttamente disponibilità e supporto delle versioni prima di passare.

OpenTofu Potrebbe Essere Rilicenziato Un Giorno?

Una futura rilicenziazione è più difficile di quanto lo sia stata per Terraform, ma non impossibile. OpenTofu è MPL 2.0, ospitato dalla Linux Foundation, ed è un progetto CNCF Sandbox dal 23 aprile 2025. La governance è multi-parte e la licenza è approvata dall'OSI. Una rilicenziazione unilaterale da parte di un singolo fondatore entrerebbe in conflitto sia con lo statuto della fondazione sia con i contributi MPL 2.0 esistenti, che dovrebbero essere rimossi o riscritti. La preoccupazione è legittima; le barriere strutturali sono reali.

Cosa Significa l'Acquisizione di HashiCorp da Parte di IBM per il Futuro di Terraform?

IBM ha completato l'acquisizione di HashiCorp il 27 febbraio 2025, per 6,4 miliardi di dollari. La roadmap di Terraform si trova ora all'interno di un fornitore enterprise più grande. L'acquisizione da sola non dimostra la futura direzione delle licenze o del prodotto; valuta le release note attuali, le indicazioni sulle licenze e i cambiamenti dei prodotti HCP invece di trattare la proprietà come una previsione.

OpenTofu È Pronto per la Produzione nel 2026?

Sì. v1.12.5 è la release di manutenzione attuale, il progetto è nel CNCF Sandbox, e Fidelity ha descritto un'adozione in produzione su un'infrastruttura IaC con oltre 50.000 file di state e quattro milioni di risorse. Pronto per la produzione non significa identico dal punto di vista delle funzionalità: i team che dipendono da capacità esclusive di HCP come Terraform Stacks devono comunque prendere una decisione di compatibilità separata.