OpenTofu Dijelaskan: Fork Terraform, Migrasi, dan Apakah Perlu Beralih

Buka modul Terraform hari ini dan Anda akan menghadapi pertanyaan yang tidak ada tiga tahun lalu: apakah biner yang menjalankan kode ini terraform, atau tofuatau? IBM telah menyelesaikan akuisisi HashiCorp pada 27 Februari 2025 senilai $6,4 miliar, dan OpenTofu menjadi proyek CNCF Sandbox pada 23 April 2025, dan jalur migrasi antara kedua alat ini kini terdokumentasi secara resmi. Keputusan ini bukan lagi hipotetis.

Artikel ini ditulis dari perspektif operasi infrastruktur, bukan dari perspektif platform Terraform terkelola. Tujuannya adalah memisahkan biaya migrasi yang sebenarnya dari kebisingan seputar lisensi dan tata kelola. Itu berarti saya bisa jujur soal apa yang rusak saat migrasi, pertanyaan tata kelola yang sah, dan kasus-kasus di mana tetap menggunakan Terraform adalah keputusan yang tepat.

Artikel ini membahas empat hal: apa itu OpenTofu di 2026, fitur yang tidak dimiliki Terraform, seperti apa migrasi dalam praktiknya, dan rekomendasi jelas untuk bentuk keputusan yang umum.

Versi Singkat

• OpenTofu adalah fork open-source dari Terraform, berlisensi MPL 2.0, dihosting oleh Linux Foundation, dan menjadi proyek CNCF Sandbox sejak 23 April 2025. Proyek ini bercabang dari Terraform 1.5.x setelah HashiCorp memindahkan Terraform ke Business Source License pada Agustus 2023.
• Per 26 Juli 2026, rilis pemeliharaan saat ini adalah v1.12.5; repositori GitHub memiliki lebih dari 29.000 bintang, dan situs proyek OpenTofu mendaftar 3.900+ provider dan 23.600+ modul.
• Ini menghadirkan kemampuan yang hanya dimiliki OpenTofu atau di mana OpenTofu memimpin, yang saat ini belum ditandingi Terraform dengan cara yang sama: enkripsi state dan plan sisi klien, provider for_each, evaluasi variabel dini, enabled meta-argument, dan dynamic prevent_destroy. Sumber daya ephemeral bukan eksklusif OpenTofu; Terraform telah mendukungnya sejak 1.10.
• Untuk proyek Terraform 1.5.x kecil dengan state lokal atau S3, jalur mudahnya bisa berupa migrasi singkat yang dapat dibalik. Referensi CI/CD, workflow khusus HCP, dan perubahan dependency-lock adalah bagian yang membuat pekerjaan bertambah.
• Untuk proyek IaC baru di 2026, mulailah dengan OpenTofu. Untuk deployment Terraform yang sudah ada, beralihlah saat BSL mulai membatasi, saat Anda butuh fitur yang dimiliki OpenTofu tapi tidak Terraform, atau saat roadmap yang dikendalikan IBM menjadi kekhawatiran nyata. Selain itu, rasio biaya-manfaatnya tipis.

Apa Itu OpenTofu di 2026

OpenTofu adalah fork open-source dari Terraform, dihosting oleh Linux Foundation, diterima ke CNCF sebagai proyek Sandbox pada 23 April 2025, dan berlisensi Mozilla Public License 2.0. Binary-nya bernama tofu. Bahasa konfigurasinya adalah HCL, HCL yang sama yang digunakan Terraform. Untuk sebagian besar proyek sederhana hingga menengah, codebase Terraform yang ada berjalan tanpa perubahan di OpenTofu.

Fork ini dimulai pada Agustus 2023 setelah HashiCorp memindahkan Terraform dari MPL 2.0 ke Business Source License 1.1 pada 10 Agustus 2023. BSL bersifat source-available, bukan disetujui OSI, dan membatasi penggunaan produksi yang "bersaing dengan penawaran komersial HashiCorp". Dalam lima hari, OpenTF Manifesto diterbitkan dan fork diumumkan. Pengumuman Linux Foundation secara resmi memperkenalkan OpenTofu pada 20 September 2023.

Pengumuman Linux Foundation menyebut Harness, Gruntwork, Spacelift, env0, Scalr, Digger, Terrateam, Massdriver, dan Terramate sebagai pendukung pendiri, dengan setidaknya 18 insinyur berkomitmen penuh waktu selama minimal lima tahun. OpenTofu bercabang dari Terraform 1.5.x, lini MPL 2.0 terakhir.

Di mana proyek ini berdiri sekarang: v1.12.5 adalah rilis pemeliharaan saat ini, dan situs resmi mendaftar 3.900+ provider dan 23.600+ modul. Sinyal adopsi tidak lagi terbatas pada momentum fork protes: studi kasus migrasi Fidelity menjelaskan program yang mencakup lebih dari 50.000 file state dan empat juta resource.

Konteks bisnis yang relevan: IBM menyelesaikan akuisisi HashiCorp pada 27 Februari 2025 senilai $6,4 miliar. Roadmap Terraform kini ditetapkan di dalam vendor enterprise yang jauh lebih besar. Itu tidak otomatis baik atau buruk bagi pengguna, tapi menjadi bagian dari perhitungan yang dibuat tim-tim di 2026.

Perbedaan OpenTofu dari Terraform

Sejak fork, kedua proyek ini mengambil jalur fitur yang berbeda. Tabel di bawah adalah versi singkatnya; catatan berikut menjelaskan apa yang diubah tiap perbedaan bagi para praktisi.

Sisi klien enkripsi state (v1.7.0, 30 April 2024). OpenTofu dapat mengenkripsi file state dan plan di dalam tool itu sendiri dengan PBKDF2, AWS KMS, GCP KMS, atau OpenBao. Terraform umumnya mendelegasikan enkripsi saat diam ke backend yang dipilih, sementara state lokal tetap plaintext. Enkripsi sisi klien OpenTofu dapat melindungi objek state yang dicuri atau plan yang di-cache, asalkan kunci dekripsi tidak terekspos bersamanya. Ini tidak menggantikan TLS, kontrol akses backend, atau disiplin manajemen secret.

Konfigurasinya kira-kira seperti ini:

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

Penyedia for_each (v1.9). Anda dapat mengiterasi konfigurasi provider seperti mengiterasi resource. Untuk pengaturan multi-region atau multi-akun, ini menghilangkan satu kelas workaround yang sudah lama ada. Anda tidak perlu lagi membuat manual satu provider beralias per region; Anda bisa menjalankan satu blok dari sebuah map.

Evaluasi variabel dini (v1.8). Variabel kini bisa dirujuk di tempat yang sebelumnya dibatasi, termasuk argumen backend dan module source. Ini berguna saat satu root module menjalankan beberapa environment yang hanya berbeda pada sekumpulan kecil variabel.

Sumber daya ephemeral dan enabled meta-argument (v1.11.0, 9 Desember 2025). OpenTofu 1.11 menambahkan sumber daya ephemeral dan enabled meta-argument. Sumber daya ephemeral hanya ada dalam satu siklus plan/apply dan tidak tersimpan di state, yang berguna untuk kredensial berumur pendek. Fitur ini bukan eksklusif OpenTofu: Terraform memperkenalkannya di 1.10 dan menambahkan argumen write-only di 1.11. Kemampuan spesifik OpenTofu di sini adalah enabled, yang mengalihkan blok resource dari sebuah ekspresi tanpa akrobat count count.

Dinamis prevent_destroy (v1.12). Pengaturan prevent_destroy Terraform hanya menerima nilai literal. OpenTofu 1.12 memungkinkan Anda menghitungnya, sehingga satu modul bisa membuat staging tetap dapat dihapus sambil melindungi production.

Baris lisensi adalah perbedaan struktural yang tidak muncul sebagai fitur. MPL 2.0 disetujui OSI dan copyleft tingkat file. Lisensi BSL 1.1 Terraform bersifat source-available, mencakup pembatasan penggunaan tambahan, dan berubah menjadi MPL 2.0 empat tahun setelah tiap karya berlisensi diterbitkan. Bagi kebanyakan tim efek praktisnya kecil; bagi vendor yang membangun sesuatu yang mendekati penawaran komersial HashiCorp, itulah alasan fork ini ada.

Migrasi: Apa yang Sebenarnya Rusak

Panduan migrasi resmi sengaja dibuat singkat dan dapat dibalik: cadangkan state dan kode, instal OpenTofu, jalankan tofu init, bandingkan tofu plan, dan uji perubahan kecil. Bagian yang sulit bukan perintahnya. Melainkan referensi CI/CD di sekitarnya, workflow khusus HCP, perubahan dependency-lock, dan tinjauan organisasi yang menyertai adopsi sebuah fork.

Jalur Mudah

Untuk proyek yang tidak menggunakan HCP Terraform dan tidak memiliki ribuan referensi pipeline ke terraform, migrasinya cukup mudah.

# 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 harus cocok dengan plan yang dihasilkan Terraform. Jika ada perbedaan tak terduga, periksa versi provider, pengaturan backend, dan fitur Terraform pasca-1.5.x sebelum menerapkan.

Ada dua nuansa penting sebelum Anda menjalankan apa pun. Pertama, OpenTofu secara luas kompatibel konfigurasi dengan HCL gaya Terraform untuk kasus yang dijelaskan panduan ini, tapi fitur yang ditambahkan setelah Terraform 1.5.x tetap perlu pemeriksaan kompatibilitas. Kedua, tofu init -upgrade dapat memperbarui .terraform.lock.hcl, termasuk alamat sumber provider dan entri checksum. Tinjau metadata itu secara terpisah dari infrastructure drift.

Penghambat Sesungguhnya

Tiga hal dapat mengubah migrasi CLI cepat menjadi proyek platform yang lebih luas. Tidak satu pun dari itu adalah bug.

Workspace HCP Terraform. OpenTofu menyertakan integrasi cloud dan remote untuk layanan remote yang kompatibel, termasuk HCP Terraform dalam skenario eksekusi lokal dan penyimpanan state. Bagian yang lebih sulit adalah eksekusi remote khusus HCP dan fitur platform: Sentinel, run trigger, kredensial dinamis, Stacks, dan perilaku layanan apa pun yang tidak bisa sepenuhnya diuji atau didukung OpenTofu. Jika itu semua penting, uji coba satu workspace dulu; jika Anda meninggalkan HCP, migrasikan state dan bangun ulang kontrol platform tersebut.

Tips Pro: Meninggalkan HCP Terraform bisa menjadi biaya tersembunyi terbesar jika estate bergantung pada workflow khusus HCP. Sebelum memutuskan, jalankan terraform state pull > state.json dan periksa ukuran serta jumlah resource. Satu workspace dengan 200 resource adalah proyek yang berbeda dari armada 50 workspace dengan run trigger dan policy set. Yang terakhir adalah migrasi platform engineering, bukan sekadar penggantian tool.

Pipeline CI/CD yang di-hardcode untuk terraform. Setiap referensi ke terraform plan, terraform apply, jalur binary, image Docker, dan langkah GitHub Actions atau GitLab CI perlu ditinjau. Untuk GitHub Actions, penggantiannya kira-kira seperti ini:

# 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

Itu kasus sepele: satu workflow, satu repo. Dalam monorepo dengan composite action bersama, banyak pipeline, dan pustaka workflow yang dapat digunakan ulang, area tinjauannya lebih luas. Pekerjaannya mekanis, tapi bisa memakan waktu lebih lama daripada penggantian CLI.

Tinjauan file dependency-lock. tofu init dapat memperbarui .terraform.lock.hcl memperbarui, termasuk alamat sumber provider dan entri checksum. OpenTofu 1.12 juga dapat menambahkan set checksum h1: lengkap. Perlakukan diff sebagai metadata dependency yang ditinjau dan di-commit terpisah, bukan infrastructure drift.

Tips Pro: Diff file lock mungkin terlihat berantakan pada commit pertama. Jalankan tofu init -upgrade di branch yang bersih, commit hanya file lock dengan pesan yang jelas seperti "review OpenTofu lock-file changes", lalu rebase pekerjaan fitur di atasnya. Mencampur metadata dependensi ke dalam PR fitur membuat kedua perubahan lebih sulit ditinjau.

Resistansi pemangku kepentingan. "Kami sekarang menjalankan fork" diterima berbeda-beda di tiap organisasi. Bantahan jujurnya adalah OpenTofu tetap kompatibel konfigurasi secara luas dengan HCL gaya Terraform untuk kasus yang dijelaskan panduan ini, jadi penggantian ini biasanya dapat dibalik. Jika OpenTofu menghilang besok, banyak tim bisa memasang ulang Terraform, meninjau file lock, dan tetap memakai .tf file .tf yang sama. Validasi dulu fitur pasca-fork; peringatan itu lebih kredibel daripada menjanjikan interoperabilitas sempurna.

Ketika Migrasi Benar-Benar Sulit

Jalur mudah itu tidak berlaku untuk semua estate Terraform.

Migrasi menjadi jauh lebih sulit ketika:

• state berukuran besar (ribuan resource, puluhan workspace) dan berada di HCP Terraform.
• codebase menggunakan fitur khusus HCP secara mendalam: kebijakan Sentinel yang terhubung ke workspace, run trigger, kredensial provider dinamis yang dikelola HCP. Terraform Stacks eksklusif HCP dan tidak punya padanan di OpenTofu, di luar cakupan di sini.
• audit enterprise atau kerangka kepatuhan menyebut "Terraform" sebagai alat IaC resmi, yang menjadi masalah pengadaan dan dokumentasi di atas masalah teknisnya.
• pustaka modul besar memiliki batasan versi internal yang diselesaikan berdasarkan perilaku registry khusus Terraform.

Tidak setiap tim harus bermigrasi. Perhitungan biaya-manfaat hanya masuk akal ketika batasan BSL benar-benar memengaruhi kasus penggunaan Anda, ketika fitur OpenTofu tertentu membuka sesuatu yang konkret, atau ketika roadmap yang dikendalikan IBM menjadi kekhawatiran nyata bagi organisasi Anda. Jika tak satu pun berlaku, tetap menggunakan Terraform adalah keputusan yang sepenuhnya masuk akal.

Haruskah Anda Beralih?

Tidak ada satu jawaban benar di sini. Saat saya menggambar decision tree untuk sebuah tim, empat bentuk umum muncul, dan langkah yang tepat bergantung pada bentuk mana yang Anda alami.

Adopsi IaC baru (greenfield). Mulai dengan OpenTofu. Lisensinya MPL 2.0, tata kelolanya berada di bawah Linux Foundation dan CNCF, dan proyek ini punya ritme rilis yang aktif. Pembedanya mencakup enkripsi state sisi klien, provider for_each, enabled, dan dynamic prevent_destroy. Tidak ada friksi BSL yang perlu direncanakan. Ini adalah rekomendasi terkuat dalam artikel ini.

Pengguna Terraform yang sudah ada, proyek kecil-menengah. Beralihlah jika salah satu dari tiga pemicu ini terjadi. Satu: Anda menjual atau mungkin menjual produk yang bisa menyentuh pengecualian BSL "bersaing dengan HashiCorp"; perhitungan hukumnya lebih jelas di MPL 2.0. Dua: Anda butuh enkripsi state sisi klien, provider for_each, enabled, atau dynamic prevent_destroy dan workaround Terraform sudah tidak sepadan lagi untuk dipertahankan. Tiga: Anda lebih menyukai tata kelola multi-pihak dibanding roadmap vendor tunggal. Jika tak satu pun berlaku dan Terraform berjalan lancar, tetaplah di situ. Migrasi dapat dibalik di banyak estate, tapi tidak gratis.

Pengguna HCP Terraform berat. Perlakukan ini sebagai keputusan platform, bukan otomatis sebagai migrasi backend. OpenTofu bisa memakai backend remote yang kompatibel, tapi eksekusi remote khusus HCP, Sentinel, run trigger, kredensial dinamis, dan Stacks tetap perlu dinilai fitur demi fitur. Jika kontrol itu sentral, uji coba dulu. Jika Anda meninggalkan HCP karena alasan lisensi, biaya, atau tata kelola, rencanakan pekerjaan ini sebagai migrasi platform.

Mempertimbangkan Pulumi atau alternatif non-HCL lain. OpenTofu adalah jalur terdekat jika Anda ingin mempertahankan HCL dan sebagian besar workflow yang ada. Pulumi adalah pilihan platform dan bahasa yang lebih luas: TypeScript, Python, Go, atau .NET yang menjalankan API cloud. Pindah ke sana mungkin melibatkan konversi atau penulisan ulang, jadi evaluasi itu terpisah dari sekadar perubahan binary Terraform ke OpenTofu.

Ada satu hal lagi yang layak dibahas langsung: kritik yang sah bahwa OpenTofu sebagian merupakan lindung nilai bagi vendor SaaS. Sebuah utas Hacker News tentang perubahan BSL memunculkan kekhawatiran bahwa anggota pendiri proyek ini adalah platform Terraform komersial dengan motif fleksibilitas lisensi mereka sendiri. Saya menanggapi kekhawatiran itu dengan serius. Mitigasinya adalah struktur tata kelola, hosting Linux Foundation, status CNCF Sandbox, MPL 2.0 di setiap file, yang membuat relisensi di masa depan jauh lebih sulit dibanding saat dilakukan vendor tunggal. Itu tidak membuatnya mustahil. Tapi itu membuatnya cukup mahal untuk menjadi pengendali yang nyata.

Kesimpulan cepat. Untuk pekerjaan IaC baru di 2026, mulailah dengan OpenTofu. Lisensi, tata kelola, pengembangan aktif, dan fitur-fiturnya menjadikannya pilihan default yang kuat. Untuk deployment Terraform yang sudah ada, beralihlah saat salah satu dari tiga pemicu di atas berlaku; jika tidak, rasio biaya-manfaatnya tipis dan tetap bertahan pun baik-baik saja.

Setelah pilihan alat jelas, pertanyaan praktis berikutnya adalah di mana OpenTofu harus dijalankan. Keputusan itu memengaruhi penanganan secret, biaya, keterulangan, dan seberapa besar kontrol tim Anda atas lingkungan eksekusi.

Menjalankan OpenTofu Sendiri

OpenTofu adalah binary CLI. Di mana Anda menjalankannya menentukan banyak hal tentang biaya, keamanan, dan apa yang bisa Anda lakukan dengannya. Ada sekitar tiga tempat masuk akal untuk menempatkannya.

Laptop atau mesin dev. Cocok untuk plan sekali pakai, prototyping, dan proyek pribadi kecil. Ini pilihan default yang buruk untuk workflow produksi bersama kecuali remote state, locking, dan disiplin review sudah diberlakukan. Tim biasanya lebih diuntungkan dengan lingkungan eksekusi kanonis daripada bergantung pada laptop mana pun yang terakhir menjalankan tofu apply.

CI runner terkelola (GitHub Actions, GitLab CI, dll.). Jalur yang umum. opentofu/setup-opentofu action adalah pengganti langsung untuk hashicorp/setup-terraform. Ini bekerja baik untuk sebagian besar tim dan proyek. Trade-off: secret melewati layanan CI pihak ketiga, menit gratis bisa habis pada operasi state besar, dan lingkungan runner bersifat ephemeral, yang biasanya menjadi kelebihan tapi kadang keterbatasan. Lihat GitHub vs GitLab jika Anda masih memilih di antara opsi CI hosted, dan Best CI/CD Tools untuk gambaran yang lebih luas.

Runner self-hosted di VPS. Berguna saat trade-off CI terkelola sudah tidak berjalan: secret harus tetap di luar layanan pihak ketiga, menit CI menjadi mahal, atau Anda ingin cache provider yang persisten. Setupnya sederhana: VPS Linux, binary OpenTofu, agen GitHub Actions atau GitLab Runner, dan Docker untuk isolasi job. Lihat Install Docker on VPS jika bagian itu baru bagi Anda. Untuk runner tim kecil, 4 GB RAM, 2 vCPU, dan 60 GB NVMe adalah titik awal yang wajar; skalakan CPU, memori, dan storage untuk plan lebih besar dan konkurensi lebih tinggi.

Bagi tim yang butuh kontrol lebih ketat atas secret runner, cache provider persisten, atau biaya CI yang dapat diprediksi, runner self-hosted di VPS bisa masuk akal. Dalam setup itu, prioritaskan akses root, storage NVMe cepat, resizing mudah, dan CPU/RAM cukup untuk operasi plan yang lebih besar.

Cloudzy Linux VPS cocok dengan pola runner self-hosted itu dengan akses root, storage NVMe, dan ukuran yang fleksibel, sehingga Anda bisa mulai kecil dan menskalakan runner seiring bertambahnya beban kerja OpenTofu Anda.

Pertanyaan yang Sering Diajukan

Apakah OpenTofu Sama dengan Terraform?

Tidak sepenuhnya. OpenTofu dimulai sebagai fork dari Terraform 1.5.x dan tetap kompatibel konfigurasi secara luas dengan HCL gaya Terraform: file .tf .tf yang sama, provider yang sama, dan plan/apply workflow plan/apply yang sama untuk banyak proyek. Keduanya berbeda dalam lisensi dan fitur yang ditambahkan setelah fork. OpenTofu punya enkripsi state sisi klien, provider for_each, enabled, dan dynamic prevent_destroy; Terraform punya fitur pasca-fork sendiri, termasuk sumber daya ephemeral.

Apakah OpenTofu Mendukung Semua Provider Terraform Saya?

Untuk provider besar seperti AWS, GCP, Azure, Kubernetes, dan Helm, umumnya ya. OpenTofu Registry Registry OpenTofu melaporkan 3.900+ provider per Juli 2026. tofu init dapat memperbarui .terraform.lock.hcl Untuk provider niche, khusus vendor, atau baru terbit, verifikasi ketersediaan dan dukungan versi secara langsung sebelum beralih.

Bisakah OpenTofu Sendiri Dilisensikan Ulang Suatu Hari?

Relisensi di masa depan lebih sulit dibanding yang dialami Terraform, tapi bukan tidak mungkin. OpenTofu berlisensi MPL 2.0, dihosting oleh Linux Foundation, dan menjadi proyek CNCF Sandbox sejak 23 April 2025. Tata kelolanya multi-pihak dan lisensinya disetujui OSI. Relisensi sepihak oleh satu pendiri saja akan bertentangan baik dengan piagam foundation maupun kontribusi MPL 2.0 yang ada, yang harus dihapus atau ditulis ulang. Kekhawatiran ini sah; hambatan strukturalnya nyata.

Apa Arti Akuisisi HashiCorp oleh IBM bagi Masa Depan Terraform?

IBM menyelesaikan akuisisi HashiCorp pada 27 Februari 2025 senilai $6,4 miliar. Roadmap Terraform kini berada di dalam vendor enterprise yang lebih besar. Akuisisi saja tidak membuktikan arah lisensi atau produk di masa depan; evaluasi catatan rilis terkini, panduan lisensi, dan perubahan produk HCP alih-alih memperlakukan kepemilikan sebagai prediksi.

Apakah OpenTofu Siap Produksi di 2026?

Ya. v1.12.5 adalah rilis pemeliharaan saat ini, proyek ini berada di CNCF Sandbox, dan Fidelity telah menjelaskan adopsi produksi di estate IaC dengan lebih dari 50.000 file state dan empat juta resource. Siap produksi tidak berarti identik fitur: tim yang bergantung pada kemampuan khusus HCP seperti Terraform Stacks tetap butuh keputusan kompatibilitas terpisah.