Masalah Kecil Bernama .env: Aman di Lokal, Berantakan di Production

Posted By

on

Masalah Kecil Bernama .env Aman di Lokal, Berantakan di Production

File .env selalu terasa seperti teman baik. Diam, membantu, dan jarang merepotkan. Di local development, semuanya terasa aman. Kita menyimpan API key, database URL, secret token, dan berbagai konfigurasi lain tanpa banyak berpikir. Tinggal copy, paste, jalan.

Masalahnya, .env hampir selalu terasa terlalu aman.

Saya sering menganggap .env sebagai detail kecil yang bisa dibereskan belakangan. Yang penting aplikasinya jalan dulu. Selama di local tidak ada masalah, rasanya semua baik-baik saja. Sampai suatu hari aplikasi itu benar-benar harus jalan di production.

Di situlah .env mulai menunjukkan sisi lain dari dirinya.

Error yang muncul sering kali tidak jelas. Kadang aplikasi tidak bisa connect ke database. Kadang API eksternal gagal tanpa pesan yang masuk akal. Kadang semuanya terlihat normal, tapi hasilnya salah. Debugging pun dimulai dari mana-mana: kode dicek, dependency dicek, bahkan logic yang sudah lama tidak disentuh ikut dicurigai.

Padahal masalahnya sederhana. Environment variable yang dipakai di production tidak sama dengan yang ada di local. Atau lebih parah lagi, tidak ada sama sekali.

Yang membuat ini menjengkelkan adalah betapa mudahnya kita lupa. .env tidak ikut ke repository, dan memang seharusnya begitu. Tapi karena tidak ikut terlihat di git, ia juga sering tidak ikut terpikirkan. Kita merasa sudah “mengirim aplikasi”, padahal yang dikirim baru separuh dari kenyataan.

Saya pernah berada di kondisi di mana aplikasi berjalan mulus di local, tapi benar-benar gagal total di production. Setelah cukup lama mencari, jawabannya hanya satu baris konfigurasi yang tidak pernah saya set di server. Tidak ada bug besar. Tidak ada arsitektur yang salah. Hanya satu environment variable yang tidak pernah ada.

Sejak itu, saya mulai melihat .env bukan sebagai file kecil, tapi sebagai bagian penting dari kontrak aplikasi. Tanpa environment yang benar, aplikasi itu sebenarnya belum lengkap. Ia hanya kebetulan bisa hidup di satu tempat.

Yang lebih berbahaya adalah rasa percaya diri palsu. Karena .env bekerja dengan baik di local, kita merasa aman. Padahal local environment sering kali terlalu “ramah”. Tidak ada limitasi, tidak ada perbedaan network, dan sering kali semua dependency tersedia. Production tidak sebaik itu.

Pelan-pelan saya belajar untuk lebih disiplin. Setiap kali ada variable baru di .env, saya anggap itu sebagai perubahan penting, bukan sekadar detail konfigurasi. Saya mulai membiasakan diri mencatatnya, entah di README, sample .env.example, atau dokumentasi internal. Bukan untuk orang lain saja, tapi untuk diri saya sendiri di masa depan.

Karena jujur saja, versi kita tiga bulan ke depan adalah orang yang berbeda. Dan dia akan sangat berterima kasih jika kita tidak meninggalkan jebakan kecil bernama .env.

Sekarang, setiap kali aplikasi gagal di production, saya selalu menahan diri untuk tidak langsung menyalahkan kode. Hal pertama yang saya cek justru environment variable-nya. Apakah semuanya ada? Apakah nilainya benar? Apakah formatnya sesuai dengan yang diharapkan aplikasi?

Anehnya, cukup sering jawabannya ada di sana.

.env memang bukan sumber bug yang menarik. Tidak ada logika rumit, tidak ada algoritma canggih. Tapi justru karena ia sederhana dan sunyi, ia sering luput dari perhatian. Dan ketika ia bermasalah, dampaknya bisa terasa jauh lebih besar dari ukurannya.

Masalahnya kecil. File-nya pun kecil. Tapi seperti banyak hal lain dalam dunia pemrograman, yang kecil dan sering diabaikan justru paling sering menyita waktu ketika salah.

Leave a comment