Deploy Staging Dibekukan: Ritual Per-Commit Digantikan Tunnel

Saya membuka dasbor pipeline pagi itu dan melihat status deploy untuk lingkungan staging membeku. Tanda centang hijau yang biasa muncul setelah setiap git push ke cabang staging kini berganti menjadi garis coret abu-abu. Ritual deploy per-commit yang selama ini jadi rutinitas tiba-tiba hilang setelah Cloudflare Tunnel mengambil alih tugas melayani staging untuk proyek KotaPortal. Tidak ada notifikasi kegagalan, hanya keheningan proses yang tidak lagi berjalan seperti sediakala.

Asumsi Awal yang Meleset

Awalnya saya menduga ada kesalahan konfigurasi pada sisi penyedia hosting frontend. Saya memeriksa log build, memastikan variabel lingkungan sudah terpasang, dan berasumsi staging tetap berjalan lewat mekanisme bawaan penyedia tersebut. Saya bahkan mencoba memicu build ulang secara manual untuk menguji hipotesis ini. Ternyata asumsi itu keliru. Masalahnya bukan pada kegagalan build, melainkan pada keputusan arsitektur yang memang sengaja diambil: komponen backend tidak lagi dideploy ke VPS setiap commit, dan pintu staging-nya dipindah total.

Yang berubah pertama justru kebiasaan harian. Dulu setiap push ke staging disusul menunggu job deploy selesai sebelum link review bisa dibagikan; sekarang link staging hidup terus dan kontennya berganti begitu proses di origin di-refresh. Sejarah commit tetap tercatat di Git, bukan di log job deploy. Freeze yang tadinya terdengar seperti mundur, setelah dilacak ternyata cuma dipindahnya titik kerja: yang dikerjakan berulang bukan lagi memindahkan berkas ke server, melainkan memastikan origin sehat dan service-nya menjawab.

Backend Tidak Ikut Pola Preview

Aplikasi yang tidak bisa tinggal di hosting preview-first, seperti API berbasis Go, panel admin internal, atau layanan yang butuh akses langsung ke basis data internal, memerlukan pintu staging yang berbeda. Di sinilah cloudflared mengubah cara kerja infrastruktur. Alat ini membuat koneksi outbound-only ke jaringan Cloudflare, sehingga server origin tidak memerlukan alamat IP publik [1].

Ini poin yang paling sering salah dipahami. Konfigurasi firewall di server origin justru boleh memblokir seluruh trafik inbound, karena semua lalu lintas yang sah datang dari dalam tunnel yang sudah terautentikasi [1]. Proses penyiapannya juga dikelola lewat dasbor. Saya memasang connector di server origin, menambahkan route bertipe published application, lalu mengarahkan Service URL ke aplikasi yang berjalan lokal di origin, pola yang sama dengan contoh di dokumentasi resmi yang menunjuk aplikasi lokal lewat HTTP [2]. Satu prasyarat mutlak sebelum mulai: server origin harus bisa menjangkau port 7844 ke jaringan Cloudflare [2]. Kalau port keluar ini diblokir aturan firewall, koneksi tidak akan pernah terbentuk dan tunnel tidak pernah online.

Buat tim kecil, pola ini juga menghapus satu class of problem: sinkronisasi versi antara staging dan mesin lokal. Selama origin menarik dari branch staging yang sama, yang dilihat reviewer dan yang dilihat developer di lokal berada di ref Git yang identik. Tidak ada lagi pertanyaan “staging ini jalan dari commit yang mana” yang harus dijawab sambil membuka log deploy lama.

Polanya kontras dengan yang sudah disediakan hosting frontend. Di sana, push ke cabang non-produksi otomatis memicu preview deployment yang terisolasi [3]. Untuk fase yang lebih panjang, ada pola cabang staging ber-domain sendiri yang mengakumulasi perubahan sebelum digabung ke produksi [4]. Pipeline CI modern menyebut target serupa sebagai environment bernama lengkap dengan protection rules [5]. Kombinasi yang saya anggap paling sehat: frontend menumpang fitur preview, backend dan aplikasi internal lewat tunnel, keduanya bertemu di workflow Git yang sama. Reviewer tidak perlu tahu ada dua mekanisme berbeda di belakangnya.

Port yang Hilang Justru sebuah Keuntungan

Kehilangan ritual deploy per-commit untuk backend bukanlah kerugian. Menghilangkan port inbound yang selama ini terbuka sebagai target deploy menaikkan postur keamanan secara langsung: penyerang tidak lagi punya pintu yang bisa dipindai. Metode lama yang mengandalkan pembatasan akses berbasis IP pada port yang tetap terbuka tidak pernah benar-benar setara, karena portnya sendiri masih ada dan tetap bisa ditemukan.

Satu jebakan kecil yang layak diingat saat konfigurasi. Kalau Service URL salah menunjuk layanan di jaringan internal yang tidak aktif, tunnel membalas 502 karena cloudflared tidak bisa menjangkau origin yang dituju. Urutan diagnosis saya setelah kejadian itu: cek nama service dan port di Service URL lebih dulu, baru menyelidiki lapisan jaringan yang lebih dalam. Mayoritas kasus berhenti di cek pertama.

Sumber

[1] Cloudflare Tunnel, Cloudflare One docs
[2] Create a tunnel (dashboard), Cloudflare One docs
[3] Vercel Docs, Environments
[4] Vercel Docs, Deploying Git Repositories
[5] GitHub Docs, Deploying with GitHub Actions