Infrastructure as Code 2026: Terraform vs OpenTofu vs Pulumi Karşılaştırması

Terraform, OpenTofu ve Pulumi: 2026’da Hangisini Seçmeli?

2026’da seçim şu üç çizgide netleşir: HashiCorp’un BSL lisansına bağlı kalmak istemeyen, açık kaynak garantisi arayan ekipler OpenTofu’ya geçer; HCL ekosistemine yatırım yapmış ve HashiCorp ticari desteği isteyen kurumlar Terraform’da kalır; gerçek programlama dili (TypeScript, Python, Go, C#) ile altyapı yazmak isteyen geliştirici-ağırlıklı ekipler Pulumi’yi tercih eder. Üçü de aynı problemi çözer: altyapıyı bildirimsel kod olarak tanımlamak ve durum (state) üzerinden yönetmek.

Kırılma noktası Ağustos 2023’tü: HashiCorp, Terraform lisansını açık kaynaktan Business Source License’a (BSL) çevirdi. Topluluk yanıtı OpenTofu oldu (Linux Foundation çatısında, MPL 2.0, Terraform ile büyük ölçüde uyumlu fork). 2026’da OpenTofu üretim olgunluğuna ulaştı ve birçok kurum migrasyonu tamamladı. Bu rehber üç aracı lisans, dil, ekosistem, state yönetimi ve kurumsal destek boyutlarında sayısal olarak karşılaştırır.

Lisans Farkı: BSL, MPL ve Apache 2.0

Seçimin en stratejik ekseni lisanstır, çünkü uzun vadeli bağımlılık ve maliyet riskini belirler. Terraform’un BSL’si, “HashiCorp’un ticari ürünleriyle rekabet eden” kullanımları kısıtlar; bu, çoğu son kullanıcıyı doğrudan etkilemese de ekosistemdeki SaaS sağlayıcılarını ve uzun vadeli güveni etkiler. OpenTofu MPL 2.0 ile tam açık kaynaktır. Pulumi ise çekirdeği Apache 2.0, yönetim katmanı (Pulumi Cloud) ticari hizmettir.

OpenTofu’nun en büyük avantajı, mevcut Terraform kodunuzun çoğunu neredeyse değişiklik gerektirmeden çalıştırabilmesidir. OpenTofu migrasyon ve modül ekosistemi bu geçişi adım adım açar.

Lisans farkının pratik önemi çoğu zaman küçümsenir, çünkü BSL kısıtlaması son kullanıcıyı doğrudan etkilemez gibi görünür. Ancak risk, uzun vadeli ekosistem sağlığında ve tedarikçi bağımlılığındadır. BSL, Terraform’u “HashiCorp’un ticari ürünleriyle rekabet eden” kullanımlarda kısıtlar; bu, Terraform üzerine SaaS sunan araç sağlayıcılarını ve bazı yönetilen hizmetleri belirsiz bir hukuki konuma sokar. Bu belirsizlik, ekosistemin etrafında gelişen üçüncü taraf araç çeşitliliğini zamanla daraltabilir. Bir kurumun altyapı yönetim aracı, beş on yıllık bir yatırımdır; bu sürede lisans koşullarının tek taraflı değişebilmesi, satıcı bağımlılığı (vendor lock-in) riskinin somut bir biçimidir. OpenTofu’nun Linux Foundation çatısı altında, topluluk yönetişimiyle ve MPL 2.0 ile sunulması tam olarak bu riski ortadan kaldırmayı hedefler; lisansın geriye dönük değiştirilemeyeceği, bağımsız bir vakıf tarafından garanti altına alınır. Lisans riskine duyarlı kamu kurumları, finans kuruluşları ve uzun ömürlü platformlar için bu garanti tek başına belirleyici olabilir.

Yapılandırma Dili: HCL mi Gerçek Programlama Dili mi?

Terraform ve OpenTofu, HashiCorp Configuration Language (HCL) kullanır: bildirimsel, alana özel ve okunması kolay ama döngü, koşul ve soyutlamada sınırlı bir dildir. Pulumi ise gerçek programlama dilleriyle altyapı yazmanızı sağlar: TypeScript ile döngü kurar, Python ile fonksiyon yazar, mevcut test araçlarını ve IDE desteğini kullanırsınız.

• HCL avantajı: Düşük öğrenme eğrisi, ops ekipleri için okunabilir, geniş örnek havuzu.
• HCL sınırı: Karmaşık mantık (count, for_each, dynamic) zorlaşır, soyutlama yetersiz kalır.
• Pulumi avantajı: Tam dil gücü, birim testi, kod tekrarını fonksiyonla önleme, IDE otomatik tamamlama.
• Pulumi sınırı: Geliştirici bilgisi gerektirir, ops-ağırlıklı ekiplerde öğrenme eğrisi yüksek.

Karar, ekibinizin profiline bağlıdır: ops-ağırlıklı ekipler HCL’in netliğini sever, geliştirici-ağırlıklı ekipler Pulumi’nin programlanabilirliğini. Terraform ile altyapı kod olarak yönetimi HCL temellerini derinleştirir.

HCL ile gerçek programlama dili arasındaki tercih, basit bir sözdizimi tercihi değil, bir bakım felsefesi seçimidir. HCL’in bildirimsel doğası, altyapıyı okunabilir ve öngörülebilir kılar; bir HCL dosyasına bakan herkes, ne olacağını yan etkilerden endişe etmeden görebilir. Bu, özellikle geniş ve karışık ekiplerde değerlidir çünkü dilin kendisi karmaşık mantığı zorlaştırarak kodu sade tutar. Ancak bu sadelik, tekrarın arttığı büyük tabanlarda dezavantaja dönüşür: count, for_each ve dynamic bloklarla kurulan döngüler okunması zor, hata ayıklaması daha da zor yapılar üretir. Pulumi’nin gerçek dil yaklaşımı tam burada öne çıkar; bir döngü, gerçek bir for döngüsüdür, bir soyutlama gerçek bir sınıf veya fonksiyondur ve mevcut birim test çerçeveleriyle altyapı mantığı test edilebilir. Bunun bedeli, dilin tam gücünün aynı zamanda tam karmaşıklığını da getirmesidir; yanlış kullanılan bir soyutlama, HCL’de hiç mümkün olmayan türden gizli, anlaşılması güç hatalar yaratabilir. Pratikte ekipler, Pulumi kullanırken bile tek bir dilde standartlaşarak ve paylaşılan bir bileşen kütüphanesi kurarak bu karmaşıklığı sınırlar.

State Yönetimi: Üç Aracın Yaklaşımı

Üç araç da çalışma için bir state (durum) dosyasına dayanır: bu dosya, kodun tanımladığı kaynakların gerçek dünyadaki karşılığını izler. State’in güvenli, kilitli ve paylaşımlı tutulması ekip çalışmasının temelidir; yanlış yönetilen state, çakışma ve veri kaybı riski yaratır.

OpenTofu 1.7 ile gelen yerleşik state şifreleme, Terraform’a göre belirgin bir güvenlik avantajıdır. State kilitleme ve uzak backend kurulumu için remote locking ve workspace en iyi pratikleri referans alınmalıdır.

Ekosistem, Sağlayıcı ve Modül Desteği

Bir IaC aracının değeri, sağlayıcı (provider) ve modül ekosisteminin genişliğiyle ölçülür. Terraform Registry binlerce provider ve modül barındırır; OpenTofu kendi registry’sini kurdu ancak Terraform provider’larıyla geniş ölçüde uyumlu çalışır. Pulumi, Terraform provider’larını köprüleyerek (bridge) kullanabilir, bu da geniş kaynak desteği sağlar.

• Terraform Registry: En büyük resmi ekosistem, binlerce doğrulanmış modül.
• OpenTofu Registry: Topluluk odaklı, Terraform provider’larıyla uyumlu, hızlı büyüyor.
• Pulumi paketleri: Native provider’lar + Terraform bridge ile geniş kapsam, dil paket yöneticisiyle dağıtılır.
• Çoklu bulut: Üçü de AWS, Azure, GCP ve Kubernetes’i tam destekler.

Çoklu bulut stack yönetiminde Pulumi ile çoklu bulut stack yönetimi programlanabilir soyutlamanın gücünü gösterir.

Ekosistem olgunluğu, bir aracın günlük kullanımında en çok hissedilen faktördür. Terraform Registry, yıllar içinde birikmiş, doğrulanmış (verified) sağlayıcı ve modüllerin en geniş havuzunu sunar; bir AWS kaynağı veya bir Kubernetes operatörü için neredeyse her zaman hazır, test edilmiş bir modül bulunur. OpenTofu, fork sonrası kendi registry’sini hızla kurdu ve mevcut Terraform provider’larının büyük çoğunluğuyla uyumlu çalışacak şekilde tasarladı; bu nedenle pratikte ekosistem farkı çoğu kurum için fark edilmez düzeydedir. Pulumi’nin yaklaşımı ise iki yönlüdür: hem kendi yazdığı native sağlayıcıları sunar hem de Terraform provider’larını bir köprü (bridge) aracılığıyla kullanabilir, böylece Terraform’un geniş kaynak desteğinden faydalanır. Pulumi paketleri ayrıca her dilin kendi paket yöneticisiyle (npm, pip, NuGet) dağıtıldığı için, geliştiriciler bağımlılıkları zaten bildikleri araçlarla yönetir. Sonuç olarak üç araç da AWS, Azure, GCP ve Kubernetes’i tam destekler; gerçek ayrım, kaynak kapsamından çok, ekibinizin bu kaynakları hangi paradigmayla (bildirimsel HCL mi, programlanabilir dil mi) yönetmek istediğindedir.

CI/CD Entegrasyonu ve Politika Olarak Kod

IaC’nin gerçek değeri, otomatik bir pipeline içinde çalışınca ortaya çıkar. Üç araç da CI/CD ile entegre olur; plan/preview aşaması her Pull Request’te çalıştırılır, değişiklik gözden geçirilir ve onaydan sonra apply edilir. Güvenlik ve uyumluluk için ise politika olarak kod (policy as code) katmanı eklenir: izinsiz kaynak tipleri, etiketsiz kaynaklar veya güvenlik dışı yapılandırmalar daha apply edilmeden engellenir.

1. Plan/preview: Her PR’de değişiklik önizlemesi otomatik üretilir, gözden geçiren ne olacağını görür.
2. Politika denetimi: OPA/Conftest, Sentinel veya Checkov ile kurallar otomatik kontrol edilir.
3. Onay ve apply: İnsan onayı sonrası değişiklik kontrollü uygulanır, state güncellenir.
4. Drift kontrolü: Zamanlanmış plan, manuel değişiklikleri yakalar ve uyumsuzluğu raporlar.

OpenTofu’nun açık ekosistemi, Conftest ve Checkov gibi vendor-bağımsız araçlarla uyumludur; Pulumi ise politikayı da kod olarak yazmanıza izin veren native CrossGuard ile öne çıkar.

Kurumsal Karar Kriterleri ve Maliyet

Kurumsal seçim teknik tercihten çok risk ve maliyet yönetimidir. Lisans belirsizliği, satıcı bağımlılığı (vendor lock-in), ekip yetkinliği ve uzun vadeli destek dengelenir. Aşağıdaki karar matrisi tipik senaryoları özetler.

Migrasyon Stratejisi: Riski Düşürerek Geçiş

Terraform’dan OpenTofu’ya geçiş, birçok ekibin sandığından düşük risklidir ama yine de disiplinli bir sıra gerektirir. OpenTofu büyük ölçüde drop-in uyumlu olduğundan, geçiş kodu yeniden yazmaktan değil, çalıştırıcıyı (binary) değiştirmekten ibarettir; ancak kritik olan, state dosyasına dokunmadan önce farkı doğrulamaktır. Güvenli geçişin altın kuralı, önce bir kopya üzerinde çalışmaktır: mevcut state yedeklenir, bir dev veya staging ortamında tofu plan çalıştırılır ve çıktının “no changes” (değişiklik yok) demesi beklenir. Eğer plan beklenmedik değişiklikler gösteriyorsa, bu genellikle bir provider sürüm farkından kaynaklanır ve lock dosyası hizalanarak çözülür. Plan temiz olduğunda, geçiş kademeli olarak, önce kritik olmayan modüllerden başlayarak üretime taşınır.

Pulumi’ye geçiş ise tamamen farklı bir doğaya sahiptir çünkü dil değişir; HCL kodu doğrudan TypeScript veya Python’a dönüşmez. Pulumi, mevcut Terraform durumunu içe aktaran (import) araçlar sunar ve HCL’i otomatik dönüştüren yardımcılar barındırır, ancak sonuç genellikle elle gözden geçirme ve yeniden düzenleme gerektirir. Bu nedenle Pulumi’ye geçiş, bir lisans kaçışı değil, programlanabilirlik ihtiyacının netleştiği bilinçli bir mimari karar olduğunda mantıklıdır. Her iki geçişte de değişmeyen bir gerçek vardır: state, sistemin gerçeğin tek kaynağıdır ve geçiş sırasında en korunması gereken varlıktır. State’in bozulması, kodun yeniden yazılmasından çok daha pahalı bir kayıptır; bu yüzden her geçiş, state yedeği ve geri dönüş planıyla başlar.

Tipik Sorunlar ve Çözümleri

IaC araç seçimi ve migrasyonu sırasında en sık karşılaşılan sorunlar genellikle state ve uyumlulukla ilgilidir. Doğrudan çözümleri şunlardır:

• Migrasyon korkusu: Terraform’dan OpenTofu’ya geçiş riskli sanılır. Çözüm: OpenTofu büyük ölçüde drop-in uyumludur; önce dev ortamda tofu plan ile doğrula, state’i değiştirmeden test et.
• State çakışması: Ekip aynı state’i kilitsiz değiştirir. Çözüm: remote backend + state locking (DynamoDB vb.) zorunlu kıl.
• Provider sürüm sürüklenmesi: Farklı makinelerde farklı provider sürümü. Çözüm: lock dosyasını (.terraform.lock.hcl) commit et, sürümleri sabitle.
• Secret sızıntısı: State içinde düz metin sır kalır. Çözüm: OpenTofu yerleşik şifreleme veya Pulumi secret kullan, state’i şifrele.
• Pulumi öğrenme eğrisi: Ops ekibi dil bilmiyor. Çözüm: tek dilde standartlaş, paylaşılan bileşen kütüphanesi kur.
• Drift: Manuel konsol değişikliği kodla uyumsuz. Çözüm: düzenli plan/preview çalıştır, politika ile manuel değişikliği engelle.

Sonuç ve Öneriler

2026’da üç araç da olgun ve üretime hazırdır; seçim teknik üstünlükten çok strateji ve ekip profiliyle yapılır. Açık kaynak garantisi ve lisans bağımsızlığı önceliğinizse OpenTofu en güvenli liman; mevcut büyük bir Terraform tabanınız varsa drop-in migrasyon ile düşük riskle geçersiniz. HashiCorp ticari desteği ve HCP entegrasyonu kritikse Terraform’da kalmak mantıklı. Geliştirici-ağırlıklı, çok dilli bir platform ekibiyseniz Pulumi’nin gerçek programlama dili gücü kod tekrarını ve karmaşık mantığı en iyi yönetir. Hangi aracı seçerseniz seçin, state’i remote ve kilitli tutun, lock dosyasını commit edin, sırları şifreleyin ve drift’i düzenli kontrol edin.

Sıkça Sorulan Sorular