TACOS menyatukan plan, policy, drift, dan kolaborasi tim dalam satu platform. Episode ini meninjau dukungan OpenTofu di Spacelift, env0, dan Scalr, lalu memperkenalkan Digger, tool GitOps open-source yang mengeksekusi OpenTofu langsung di CI tanpa SaaS eksternal.

Di episode 13 sebelumnya kita membangun pipeline GitOps penuh di GitHub Actions dan GitLab CI: action resmi setup-opentofu, tofu fmt, tofu validate, security scan, tofu plan dengan komentar di PR, approval gate, dan tofu apply via OIDC. Pipeline semacam itu hebat — tetapi membangun dan memeliharanya untuk puluhan repositori adalah pekerjaan yang terus berlanjut. Semakin besar tim, semakin tinggi juga kebutuhan akan hal-hal yang melelahkan jika dibuat sendiri: policy enforcement, deteksi drift, pelacakan cost, dan kontrol akses yang halus. Di sinilah ekosistem managed TACOS mengambil alih.
Di episode 14 ini kita meninjau platform managed yang mendukung OpenTofu — Spacelift, env0, dan Scalr — lalu memperkenalkan Digger, tool GitOps open-source yang mengeksekusi OpenTofu langsung di dalam CI kalian tanpa SaaS eksternal.
TACOS adalah singkatan dari Terraform/OpenTofu Automation and Collaboration Software. Idenya sederhana: alih-alih mengelola init, plan, apply, state locking, policy, dan persetujuan secara terpisah, semua itu dipusatkan dalam satu lapisan di atas engine IaC. Terraform Cloud memang pernah memegang peran ini, tapi ia adalah produk komersial HashiCorp — dan komunitas OpenTofu tentu tidak ingin menggantungkan diri pada ekosistem yang sama yang membuat Terraform berubah lisensi. Maka vendor-vendor TACOS yang mendukung OpenTofu sejak awal muncul sebagai alternatif.
Ketiganya adalah platform SaaS (Scalr juga bisa diinstal sendiri di infrastruktur kalian) yang menjalankan binary tofu di balik layar. Semua mendukung OpenTofu secara native sejak fork diluncurkan — dan mereka juga merupakan sponsor awal proyek:
Spacelift — yang paling kuat dalam policy dan otomatisasi. Ia punya Policy as Code berbasis OPA/Rego untuk mengontrol siapa yang boleh plan dan apply, deteksi drift yang terjadwal, serta tampilan plan yang kaya. Banyak tim produksi memakainya sebagai pengganti Terraform Cloud.
env0 — menonjol di kemudahan pakai: template UI, RBAC, estimasi biaya, dan integrasi dengan banyak tool. Cocok untuk tim yang ingin menaikkan kapasitas engineer non-IaC dengan cepat.
Scalr — bisa dipasang di infrastruktur sendiri, mendukung remote state backend yang kompatibel dengan OpenTofu, dan sangat fokus pada governance serta RBAC yang halus.
| Platform | Model | Kekuatan utama | OpenTofu |
|---|---|---|---|
| Spacelift | SaaS | Policy as Code, drift, plan kaya | Native |
| env0 | SaaS | Template UI, cost estimation | Native |
| Scalr | SaaS / self-hosted | Remote backend, RBAC halus | Native |
Note
Tidak ada ikon khusus untuk Spacelift, env0, maupun Digger dalam set ikon blog ini. Konfigurasi mereka di episode ini memakai ikon generik yang tersedia: iTofu, iBash, iGithubactions, dan iGitlab sebagai gantinya.
Jika Spacelift dan kawan-kawan adalah SaaS yang kalian bayar, Digger mengambil jalan sebaliknya: open-source dan berjalan di CI yang sudah kalian miliki. Digger membaca konfigurasi digger.yml, mendengar event pull request dan issue comment dari GitHub atau GitLab, lalu mengeksekusi OpenTofu langsung di runner — tidak ada cloud eksternal, tidak ada data yang meninggalkan repository, dan tanpa biaya langganan.
Konfigurasi Digger berbasis proyek dan workflow. Setiap proyek menunjuk ke direktori dan workflow yang dipakainya, dan setiap workflow mendefinisikan langkah plan serta apply:
projects:
- name: dev-vpc
dir: terragrunt/dev/vpc
workflow: dev
- name: prod-app
dir: tofu/prod/app
workflow: prod
workflows:
dev:
plan:
steps:
- init
- plan
apply:
steps:
- apply
prod:
plan:
steps:
- init
- plan
apply:
steps:
- apply
auto_merge: true
comment_on_pr: trueKunci dari GitOps adalah bahwa state infrastruktur mengikuti state repository. Dengan Digger, plan berjalan otomatis saat PR dibuka atau diperbarui, hasilnya dikomentari langsung di PR, dan apply terjadi setelah merge — atau bisa ditambah persetujuan manual lewat komentar. Otorisasi diatur lewat Policy as Code OPA bawaan, dan drift bisa dideteksi dengan job terjadwal.
Integrasinya ke GitHub Actions cukup dengan action diggerhq/digger:
name: Digger
on:
pull_request:
types: [opened, synchronize, reopened, closed]
issue_comment:
types: [created]
jobs:
digger:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: diggerhq/digger@v0.7.10
with:
setup-aws: true
env:
GITHUB_CONTEXT: ${{ toJson(github) }}
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}Tip
Digger juga punya command CLI langsung: digger plan dan digger apply berjalan di runner lokal kalian. Ini membuat onboarding sangat ringan — cukup pasang action, tulis digger.yml, dan biarkan PR pertama memposting plan pertamanya.
Tidak ada jawaban universal. Platform managed menghemat waktu mengembangkan fitur yang melelahkan — policy engine, drift scheduler, dan UI — tetapi menyerahkan eksekusi ke pihak ketiga dan menambah biaya per pengguna. Digger mengembalikan kontrol penuh dan biaya nol, tapi kalian bertanggung jawab memelihara workflow CI dan menambah sendiri fitur-fitur yang platform managed berikan gratis. Aturan praktisnya: tim kecil dengan beberapa repo memulai dari Digger, tim besar dengan kebutuhan governance serius menengok Spacelift atau Scalr.
Pada episode 14 ini kita telah:
digger.yml dan menghubungkannya ke workflow CI.Semua platform di episode ini — baik SaaS maupun Digger — berasumsi rahasia yang dikirim ke OpenTofu aman. Di episode 15 selanjutnya kita mengamankan asumsi itu: secret management & state hardening dengan menggabungkan client-side state encryption dan sensitive variables, lalu menarik rahasia dinamis dari HashiCorp Vault, AWS Secrets Manager, atau GCP Secret Manager saat apply. Sampai jumpa!