OpenTofu Açıklandı: Terraform Fork'u, Geçiş ve Değişip Değişmeme Kararı

Bugün bir Terraform modülü açtığınızda üç yıl önce var olmayan bir soruyla karşılaşırsınız: bu kodu çalıştıran ikili dosya terraform, yoksa tofumi olmalı? IBM, HashiCorp satın almasını 27 Şubat 2025'te 6,4 milyar dolara tamamladı, OpenTofu ise CNCF Sandbox projesi haline geldi 23 Nisan 2025'te. İki araç arasındaki geçiş yolu artık resmi olarak belgelenmiş durumda. Karar artık varsayımsal değil.

Bu makale, yönetilen bir Terraform platformunun bakış açısından değil, altyapı operasyonları bakış açısından yazılmıştır. Amaç, gerçek geçiş maliyetlerini lisanslama ve yönetişim gürültüsünden ayırmaktır. Bu da geçiş sırasında nelerin bozulduğu, meşru yönetişim sorularının ve Terraform'da kalmanın doğru karar olduğu durumların açıkça konuşulabileceği anlamına gelir.

Bu makale dört konuyu ele alıyor: OpenTofu'nun 2026'da ne olduğu, Terraform'da bulunmayan özellikler, geçişin pratikte nasıl göründüğü ve yaygın karar senaryoları için net bir öneri.

Kısa Versiyon

• OpenTofu, Terraform'un MPL 2.0 lisanslı, Linux Foundation tarafından barındırılan ve 23 Nisan 2025'ten beri CNCF Sandbox projesi olan açık kaynak fork'udur. HashiCorp, Terraform'u Ağustos 2023'te Business Source License'a taşıdıktan sonra Terraform 1.5.x'ten fork edilmiştir.
• 26 Temmuz 2026 itibarıyla mevcut bakım sürümü v1.12.5; GitHub deposu 29.000'den fazla yıldıza sahip ve OpenTofu proje sitesi 3.900'den fazla provider ve 23.600'den fazla modül listeliyor.
• Terraform'un şu anda aynı şekilde eşleyemediği yalnızca OpenTofu'ya özgü veya OpenTofu'nun önde olduğu yetenekler sunar: istemci taraflı state ve plan şifreleme, provider for_each, erken değişken değerlendirmesi, enabled meta-argümanı ve dinamik prevent_destroy. Geçici (ephemeral) kaynaklar yalnızca OpenTofu'ya özgü değildir; Terraform bunları 1.10'dan beri destekliyor.
• Yerel veya S3 state kullanan küçük bir Terraform 1.5.x projesi için basit yol kısa ve geri alınabilir bir geçiş olabilir. İşin genişlediği yerler CI/CD referansları, HCP'ye özgü workflow'lar ve bağımlılık kilidi değişiklikleridir.
• 2026'da yeni bir IaC projesi için OpenTofu ile başlayın. Mevcut bir Terraform dağıtımı için, BSL sıkıntı yaratmaya başladığında, OpenTofu'da olup Terraform'da olmayan bir özelliğe ihtiyaç duyduğunuzda ya da IBM'e ait yol haritası gerçek bir endişe kaynağı olduğunda geçiş yapın. Aksi halde maliyet-fayda dengesi zayıftır.

2026'da OpenTofu Nedir

OpenTofu, Linux Foundation tarafından barındırılan, 23 Nisan 2025'te CNCF'ye Sandbox projesi olarak kabul edilen ve Mozilla Public License 2.0 ile lisanslanan açık kaynaklı bir Terraform fork'udur. İkili dosyanın adı tofu. Yapılandırma dili HCL'dir, Terraform'un kullandığı HCL ile aynıdır. Çoğu basit ile orta ölçekli proje için mevcut bir Terraform kod tabanı OpenTofu üzerinde değişiklik yapılmadan çalışır.

Fork, HashiCorp'un Terraform'u MPL 2.0'dan Business Source License 1.1'e taşımasının ardından Ağustos 2023'te başladı. BSL, OSI onaylı değil, "source-available" bir lisanstır ve "HashiCorp'un ticari tekliflerine rakip olan" üretim kullanımını kısıtlar. Beş gün içinde OpenTF Manifestosu yayımlandı ve bir fork duyuruldu. Linux Foundation duyurusu OpenTofu'yu 20 Eylül 2023'te resmi olarak tanıttı.

Linux Foundation duyurusu kurucu destekçiler arasında Harness, Gruntwork, Spacelift, env0, Scalr, Digger, Terrateam, Massdriver ve Terramate'i saydı; en az 18 mühendis en az beş yıl tam zamanlı olarak taahhüt etti. OpenTofu, son MPL 2.0 sürümü olan Terraform 1.5.x'ten fork edildi.

Projenin bugün geldiği nokta: v1.12.5 mevcut bakım sürümüdür ve resmi site 3.900'den fazla provider ve 23.600'den fazla modül listeler. Benimseme sinyalleri artık sadece protesto fork'unun ivmesiyle sınırlı değil: Fidelity geçiş vaka çalışması 50.000'den fazla state dosyasını ve dört milyon kaynağı kapsayan bir programı anlatıyor.

İlgili iş bağlamı: IBM, HashiCorp satın almasını 27 Şubat 2025'te 6,4 milyar dolara tamamladı. Terraform'un yol haritası artık çok daha büyük bir kurumsal satıcının içinde belirleniyor. Bu, kullanıcılar için otomatik olarak iyi ya da kötü değil, ancak ekiplerin 2026'da yaptığı hesabın bir parçası.

OpenTofu, Terraform'dan Nerelerde Ayrılıyor

Fork'tan bu yana, iki proje farklı özellik yolları izledi. Aşağıdaki tablo kısa versiyondur; devamındaki notlar her farkın uygulayıcılar için ne değiştirdiğini açıklar.

İstemci taraflı state şifreleme (v1.7.0, 30 Nisan 2024). OpenTofu, state ve plan dosyalarını PBKDF2, AWS KMS, GCP KMS veya OpenBao ile aracın içinde şifreleyebilir. Terraform genellikle bekleme durumundaki şifrelemeyi seçilen backend'e bırakır, yerel state ise düz metin olarak kalır. OpenTofu'nun istemci taraflı şifrelemesi, şifre çözme anahtarı onunla birlikte açığa çıkmadığı sürece çalınan bir state nesnesini veya önbelleğe alınmış bir planı koruyabilir. TLS'nin, backend erişim denetimlerinin veya gizli bilgi yönetimi disiplininin yerini tutmaz.

Yapılandırma kabaca şöyle görünür:

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
    }
  }
}

Sağlayıcı for_each (v1.9). Provider yapılandırmalarını, kaynaklarda yaptığınız gibi döngüyle işleyebilirsiniz. Çoklu bölge veya çoklu hesap kurulumlarında bu, uzun süredir devam eden bir geçici çözüm sınıfını ortadan kaldırır. Artık bölge başına elle takma adlı bir provider oluşturmanıza gerek yok; tek bir bloğu bir map'ten yönetebilirsiniz.

Erken değişken değerlendirmesi (v1.8). Değişkenler artık daha önce kısıtlı olan yerlerde, backend ve modül source argümanları dahil olmak üzere referans gösterilebilir. Bu, tek bir kök modülün küçük bir değişken kümesiyle farklılaşan birden çok ortamı yönettiği durumlarda kullanışlıdır.

Geçici kaynaklar ve enabled meta-argümanı (v1.11.0, 9 Aralık 2025). OpenTofu 1.11, geçici kaynakları ve enabled meta-argümanını ekledi. Geçici kaynaklar yalnızca tek bir plan/apply döngüsü içinde var olur ve state'te kalıcı olmaz, bu da kısa ömürlü kimlik bilgileri için kullanışlıdır. Bunlar yalnızca OpenTofu'ya özgü değildir: Terraform bunları 1.10'da tanıttı ve 1.11'de yalnızca yazma argümanları ekledi. Buradaki OpenTofu'ya özgü yetenek enabled, bir kaynak bloğunu koşullu count gimnastiği olmadan bir ifadeden değiştiren enabled meta-argümanıdır.

Dinamik prevent_destroy (v1.12). Terraform'un prevent_destroy ayarı yalnızca sabit değerleri kabul eder. OpenTofu 1.12 bunu hesaplamanıza izin verir, böylece tek bir modül staging'i silinebilir bırakırken production'ı koruyabilir.

Lisans satırı, bir özellik olarak görünmeyen yapısal farktır. MPL 2.0 OSI onaylıdır ve dosya düzeyinde copyleft'tir. Terraform'un BSL 1.1 lisansı source-available'dır, ek bir kullanım kısıtlaması içerir ve her lisanslı çalışmanın yayımlanmasından dört yıl sonra MPL 2.0'a döner. Çoğu ekip için pratik etki küçüktür; HashiCorp'un ticari tekliflerine yakın bir şey inşa eden satıcılar için ise fork'un var olma nedeni tam olarak budur.

Geçiş: Gerçekte Ne Bozuluyor

Resmi geçiş kılavuzu kasıtlı olarak kısa ve geri alınabilir: state ve kodu yedekleyin, OpenTofu'yu kurun, tofu init'i çalıştırın, tofu plan ile karşılaştırın ve küçük bir değişikliği test edin. Zor kısımlar komutlar değildir. Bunlar çevredeki CI/CD referansları, HCP'ye özgü workflow'lar, bağımlılık kilidi değişiklikleri ve bir fork'u benimsemenin getirdiği organizasyonel incelemedir.

Basit Yol

HCP Terraform kullanmayan ve binlerce pipeline referansı terraform içermeyen bir proje için geçiş basittir.

# 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 Terraform'un ürettiği planla eşleşmelidir. Beklenmeyen bir fark varsa, uygulamadan önce provider sürümlerini, backend ayarlarını ve 1.5.x sonrası Terraform özelliklerini kontrol edin.

Herhangi bir şey çalıştırmadan önce iki incelik önemlidir. Birincisi, OpenTofu bu kılavuzun anlattığı durumlar için Terraform tarzı HCL ile büyük ölçüde yapılandırma uyumludur, ancak Terraform 1.5.x sonrasında eklenen özellikler yine de uyumluluk kontrolüne ihtiyaç duyar. İkincisi, tofu init -upgrade güncelleyebilir .terraform.lock.hcl, provider kaynak adresleri ve checksum girişleri dahil. Bu meta verileri altyapı sapmasından ayrı olarak inceleyin.

Gerçek Engeller

Üç şey, hızlı bir CLI geçişini daha geniş bir platform projesine dönüştürebilir. Hiçbiri hata (bug) değildir.

HCP Terraform workspace'leri. OpenTofu, uyumlu remote hizmetler için cloud ve remote entegrasyonlarını içerir , burada HCP Terraform yerel yürütme ve state depolama senaryolarında yer alır. Zor olan kısım HCP'ye özgü remote yürütme ve platform özellikleridir: Sentinel, run trigger'lar, dinamik kimlik bilgileri, Stacks ve OpenTofu'nun tam olarak test edemediği ya da desteklemediği herhangi bir servis davranışı. Bunlar merkezi öneme sahipse önce tek bir workspace'i pilot olarak deneyin; HCP'den ayrılıyorsanız state'i taşıyın ve bu platform kontrollerini yeniden oluşturun.

İpucu: HCP Terraform'dan ayrılmak, altyapı HCP'ye özgü workflow'lara bağımlıysa en büyük gizli maliyet olabilir. Karar vermeden önce terraform state pull > state.json çalıştırın ve boyutu ile kaynak sayısını inceleyin. 200 kaynaklı bir workspace, run trigger'lı ve policy set'li 50 workspace'lik bir filodan çok farklı bir projedir. İkincisi bir araç değişimi değil, bir platform mühendisliği geçişidir.

İçin sabit kodlanmış CI/CD pipeline'ları terraform. Her referans terraform plan, terraform apply, ikili dosya yolu, Docker imajı ve GitHub Actions veya GitLab CI adımı gözden geçirilmelidir. GitHub Actions için değişim kabaca şöyledir:

# 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

Bu basit bir durumdur: tek workflow, tek repo. Paylaşılan composite action'ları, birden fazla pipeline'ı ve yeniden kullanılabilir bir workflow kütüphanesi olan bir monorepo'da inceleme kapsamı daha geniştir. İş mekaniktir, ancak CLI değişiminden daha uzun sürebilir.

Bağımlılık kilit dosyası incelemesi. tofu init güncelleyebilir .terraform.lock.hcl, provider kaynak adresleri ve checksum girişleri dahil, güncelleyebilir. OpenTofu 1.12 ayrıca tüm platformlar için tam h1: checksum kümeleri de ekleyebilir. Diff'i altyapı sapması olarak değil, ayrı olarak incelenip commit edilecek bağımlılık meta verisi olarak ele alın.

İpucu: Kilit dosyası diff'i ilk commit'te gürültülü görünebilir. tofu init -upgrade temiz bir dalda, kilit dosyasını "review OpenTofu lock-file changes" gibi net bir mesajla tek başına commit'leyin, ardından özellik çalışmasını bunun üzerine rebase edin. Bağımlılık meta verilerini bir özellik PR'ıyla karıştırmak her iki değişikliği de incelemeyi zorlaştırır.

Paydaş direnci. "Artık bir fork çalıştırıyoruz" sözü, farklı organizasyonlarda farklı karşılanır. Dürüst yanıt şudur: OpenTofu, bu kılavuzun anlattığı durumlar için Terraform tarzı HCL ile büyük ölçüde yapılandırma uyumlu kalır, bu yüzden değişim genellikle geri alınabilir. OpenTofu yarın ortadan kalksa, birçok ekip Terraform'u yeniden kurabilir, kilit dosyasını gözden geçirebilir ve aynı .tf .tf dosyalarını kullanmaya devam edebilirdi. Önce fork sonrası özellikleri doğrulayın; bu uyarı, kusursuz bir değiştirilebilirlik vaat etmekten daha inandırıcıdır.

Geçiş Gerçekten Zor Olduğunda

Bu basit yol her Terraform altyapısı için geçerli değildir.

Geçiş şu durumlarda belirgin biçimde zorlaşır:

• State büyükse (binlerce kaynak, düzinelerce workspace) ve HCP Terraform içinde yaşıyorsa.
• Kod tabanı, yalnızca HCP'ye özgü özellikleri yoğun biçimde kullanıyorsa: workspace'lere bağlı Sentinel policy'leri, run trigger'lar, HCP tarafından yönetilen dinamik provider kimlik bilgileri. Terraform Stacks yalnızca HCP'ye özgüdür ve OpenTofu'da bir karşılığı yoktur, burada kapsam dışıdır.
• Bir kurumsal denetim veya uyumluluk çerçevesi "Terraform"u resmi IaC aracı olarak adlandırıyorsa, bu teknik sorunun üzerine bir satın alma ve dokümantasyon sorunu daha ekler.
• Büyük bir modül kütüphanesi, Terraform'a özgü registry davranışına göre çözülen dahili sürüm kısıtlamalarına sahipse.

Her ekibin geçiş yapması gerekmez. Maliyet-fayda dengesi, ancak BSL kısıtlamaları kullanım durumunuzu gerçekten etkiliyorsa, belirli bir OpenTofu özelliği somut bir şeyi çözüyorsa veya IBM kontrolündeki yol haritası organizasyonunuz için gerçek bir endişeyse mantıklıdır. Bunların hiçbiri geçerli değilse, Terraform'da kalmak tamamen savunulabilir bir karardır.

Geçiş Yapmalı Mısınız?

Burada tek bir doğru cevap yok. Bir ekip için karar ağacını çizdiğimde dört yaygın senaryo ortaya çıkıyor ve doğru hamle hangi senaryoda olduğunuza bağlı.

Yeni IaC benimsemesi (greenfield). OpenTofu ile başlayın. Lisans MPL 2.0'dır, yönetişim Linux Foundation ve CNCF altındadır ve projenin aktif bir yayın temposu vardır. Ayırt edici özellikleri arasında istemci taraflı state şifreleme, provider for_each, enabled, ve dinamik prevent_destroy. Etrafında plan yapılacak bir BSL sürtünmesi yoktur. Bu, bu makaledeki en güçlü öneridir.

Mevcut Terraform kullanıcısı, küçük-orta ölçekli proje. Üç tetikleyiciden herhangi biri gerçekleşirse geçiş yapın. Bir: BSL'nin "HashiCorp ile rekabet eder" istisnasına dokunabilecek bir ürün satıyor veya satabilirsiniz; hukuki hesap MPL 2.0'da daha nettir. İki: istemci taraflı state şifrelemeye, provider for_each, enabled, ya da dinamik prevent_destroy , ve Terraform geçici çözümü artık sürdürülmeye değmiyor. Üç: tek bir satıcının yol haritasına karşı çok taraflı yönetişimi tercih ediyorsunuz. Hiçbiri geçerli değilse ve Terraform sorunsuz çalışıyorsa, kalın. Geçiş birçok altyapıda geri alınabilir, ancak ücretsiz değil.

Yoğun HCP Terraform kullanıcısı. Bunu otomatik olarak bir backend geçişi değil, bir platform kararı olarak ele alın. OpenTofu uyumlu remote backend'leri kullanabilir, ancak HCP'ye özgü remote yürütme, Sentinel, run trigger'lar, dinamik kimlik bilgileri ve Stacks hâlâ özellik bazında bir değerlendirme gerektirir. Bu kontroller merkeziyse önce pilot yapın. HCP'yi lisanslama, maliyet veya yönetişim nedenleriyle terk ediyorsanız, işi bir platform geçişi olarak planlayın.

Pulumi veya HCL dışı başka bir alternatifi düşünüyorsanız. HCL'i ve mevcut workflow'ların çoğunu korumak istiyorsanız OpenTofu en yakın yoldur. Pulumi daha geniş bir platform ve dil seçimidir: cloud API'lerini yöneten TypeScript, Python, Go veya .NET. Oraya geçmek dönüştürme veya yeniden yazma gerektirebilir, bu yüzden bunu bir Terraform'dan OpenTofu'ya ikili değişimden ayrı değerlendirin.

Doğrudan ele alınmaya değer bir konu daha var: OpenTofu'nun kısmen SaaS satıcıları için bir güvence olduğu yönündeki meşru eleştiri. BSL değişikliğiyle ilgili bir Hacker News tartışması, projenin kurucu üyelerinin kendi lisans esnekliği motivasyonuna sahip ticari Terraform platformları olduğu endişesini gündeme getirdi. Bu endişeyi ciddiye alıyorum. Bunu hafifleten şey yönetişim yapısı, Linux Foundation barındırması, CNCF Sandbox statüsü ve her dosyadaki MPL 2.0'dır; bu da gelecekteki bir lisans değişikliğini tek bir satıcının yaptığından çok daha zor hale getirir. Bu, imkansız kılmaz. Ancak yeterince maliyetli hale getirerek gerçek bir denetim mekanizması oluşturur.

Hızlı özet. 2026'da yeni IaC işleri için OpenTofu ile başlayın. Lisansı, yönetişimi, aktif geliştirmesi ve özellik seti onu güçlü bir varsayılan seçim yapıyor. Mevcut Terraform dağıtımları için yukarıdaki üç tetikleyiciden biri geçerli olduğunda geçiş yapın; aksi halde maliyet-fayda dengesi zayıftır ve kalmak sorun değildir.

Araç seçimi netleştikten sonra bir sonraki pratik soru OpenTofu'nun nerede çalışması gerektiğidir. Bu karar, gizli bilgi yönetimini, maliyeti, tekrarlanabilirliği ve ekibinizin yürütme ortamı üzerindeki kontrol düzeyini etkiler.

OpenTofu'yu Kendiniz Çalıştırmak

OpenTofu bir CLI ikili dosyasıdır. Onu nerede çalıştırdığınız maliyet, güvenlik ve onunla neler yapabileceğiniz hakkında çok şey belirler. Onu koymak için kabaca üç mantıklı yer vardır.

Dizüstü bilgisayar veya geliştirme makinesi. Tek seferlik planlar, prototipleme ve küçük kişisel projeler için uygundur. Remote state, kilitleme ve inceleme disiplini zaten uygulanmıyorsa, paylaşılan production workflow'ları için kötü bir varsayılandır. Ekipler genellikle en son hangi dizüstü bilgisayar tofu apply.

Yönetilen CI runner (GitHub Actions, GitLab CI, vb.). En yaygın yol. opentofu/setup-opentofu action'ı, hashicorp/setup-terraform için doğrudan bir yerine koyma çözümüdür. Bu çoğu ekip ve proje için iyi çalışır. Değiş tokuşlar: gizli bilgiler üçüncü taraf bir CI hizmetinden geçer, büyük state işlemlerinde ücretsiz katman dakikaları tükenebilir ve runner ortamı geçicidir, ki bu genellikle bir özelliktir ama bazen bir kısıtlamadır. Bkz. GitHub vs GitLab hala barındırılan CI seçenekleri arasında karar veriyorsanız, ve Best CI/CD Tools daha geniş bir bakış için.

VPS üzerinde self-hosted runner. Yönetilen CI'nın değiş tokuşları işe yaramamaya başladığında kullanışlıdır: gizli bilgiler üçüncü taraf bir hizmetin dışında kalmalıdır, CI dakikaları pahalılaşır ya da kalıcı provider önbellekleri istersiniz. Kurulum basittir: bir Linux VPS, OpenTofu ikili dosyası, bir GitHub Actions veya GitLab Runner ajanı, ve iş izolasyonu için Docker. Bkz. Install Docker on VPS eğer bu kısım sizin için yeniyse. Küçük bir ekip runner'ı için 4 GB RAM, 2 vCPU ve 60 GB NVMe makul bir başlangıç noktasıdır; daha büyük planlar ve daha yüksek eşzamanlılık için CPU, bellek ve depolamayı ölçeklendirin.

Runner gizli bilgileri üzerinde daha sıkı kontrole, kalıcı provider önbelleklerine veya öngörülebilir CI maliyetlerine ihtiyaç duyan ekipler için VPS üzerinde self-hosted bir runner mantıklı olabilir. Bu kurulumda root erişimine, hızlı NVMe depolamaya, kolay boyutlandırmaya ve daha büyük plan işlemleri için yeterli CPU/RAM'e öncelik verin.

Cloudzy Linux VPS örnekleri, root erişimi, NVMe depolama ve esnek boyutlandırma ile bu self-hosted runner modeline uyar, böylece küçük başlayıp OpenTofu iş yükleriniz büyüdükçe runner'ı ölçeklendirebilirsiniz.

Sıkça Sorulan Sorular

OpenTofu, Terraform ile Aynı mı?

Tam olarak değil. OpenTofu, Terraform 1.5.x'in bir fork'u olarak başladı ve Terraform tarzı HCL ile büyük ölçüde yapılandırma uyumlu kalıyor: aynı .tf dosyalar, aynı provider'lar ve aynı plan/apply plan/apply workflow'u birçok proje için aynıdır. Lisansta ve fork sonrası eklenen özelliklerde farklılaşırlar. OpenTofu'da istemci taraflı state şifreleme, provider for_each, enabled, ve dinamik prevent_destroy; Terraform'un geçici kaynaklar dahil kendine ait fork sonrası özellikleri vardır.

OpenTofu Tüm Terraform Provider'larımı Destekleyecek mi?

AWS, GCP, Azure, Kubernetes ve Helm gibi büyük provider'lar için genellikle evet. OpenTofu Registry , Temmuz 2026 itibarıyla 3.900'den fazla provider bildiriyor. tofu init güncelleyebilir .terraform.lock.hcl tofu init meta verileri güncelleyebilir. Niş, satıcıya özgü veya yeni yayımlanmış provider'lar için, geçiş yapmadan önce kullanılabilirliği ve sürüm desteğini doğrudan doğrulayın.

OpenTofu'nun Kendisi Bir Gün Yeniden Lisanslanabilir mi?

Gelecekteki bir yeniden lisanslama, Terraform'da olduğundan daha zordur ama imkansız değildir. OpenTofu MPL 2.0'dır, Linux Foundation tarafından barındırılır ve 23 Nisan 2025'ten beri bir CNCF Sandbox projesidir. Yönetişim çok taraflıdır ve lisans OSI onaylıdır. Herhangi bir kurucunun tek taraflı bir yeniden lisanslaması, hem vakfın tüzüğüyle hem de kaldırılması veya yeniden yazılması gereken mevcut MPL 2.0 katkılarıyla çelişirdi. Endişe meşrudur; yapısal engeller gerçektir.

IBM'in HashiCorp'u Satın Alması Terraform'un Geleceği İçin Ne Anlama Geliyor?

IBM, HashiCorp satın almasını 27 Şubat 2025'te 6,4 milyar dolara tamamladı. Terraform'un yol haritası artık daha büyük bir kurumsal satıcının içinde yer alıyor. Satın alma tek başına gelecekteki lisanslama veya ürün yönünü kanıtlamaz; sahipliği bir tahmin olarak ele almak yerine mevcut sürüm notlarını, lisanslama rehberliğini ve HCP ürün değişikliklerini değerlendirin.

OpenTofu 2026'da Üretime Hazır mı?

Evet. v1.12.5 mevcut bakım sürümüdür, proje CNCF Sandbox'ta yer alır ve Fidelity, 50.000'den fazla state dosyası ve dört milyon kaynak içeren bir IaC altyapısı genelinde üretim benimsemesini anlatmıştır. Üretime hazır olmak, özellik açısından aynı olmak anlamına gelmez: Terraform Stacks gibi yalnızca HCP'ye özgü yeteneklere bağımlı ekiplerin hâlâ ayrı bir uyumluluk kararına ihtiyacı vardır.