Anatomi berkas .env sudah kita kuasai di Konfigurasi Environment , dan risiko keamanannya sudah dibedah di Secure Configuration . Chapter ini mengambil sudut pandang berbeda: bagaimana .env dikelola saat aplikasi pindah dari laptop ke server produksi, apa saja nilainya yang wajib berubah, dan bagaimana config:cache membekukan nilai sehingga strategi deployment harus memperhitungkannya. Kita buktikan setiap perilaku dengan perintah yang benar-benar dijalankan.

Daftar Periksa .env Produksi #

Berkas .env produksi bukan salinan dari lokal dengan satu-dua nilai diganti — hampir semua kunci penting bernilai berbeda. Berikut contoh tampilan .env yang sudah disesuaikan untuk server produksi:

dotenv 
APP_NAME="Toko Budi"
APP_ENV=production
APP_KEY=base64:YOUR_APP_KEY
APP_DEBUG=false
APP_URL=https://tokobudi.example.com

LOG_CHANNEL=stack
LOG_LEVEL=error

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_DATABASE=tokobudi_prod
DB_USERNAME=tokobudi_app
DB_PASSWORD=YOUR_DATABASE_PASSWORD

SESSION_DRIVER=redis
QUEUE_CONNECTION=redis
CACHE_STORE=redis

REDIS_HOST=127.0.0.1
REDIS_PASSWORD=YOUR_REDIS_PASSWORD

MAIL_MAILER=ses
MAIL_FROM_ADDRESS="[email protected]"

Empat keputusan penting ada di blok tersebut. Pertama, APP_ENV=production dan APP_DEBUG=false adalah saklar yang tidak bisa dinegosiasi — keduanya mengubah cara Laravel menangani error dan meminta konfirmasi pada perintah berbahaya. Kedua, LOG_LEVEL=error menahan log agar tidak membengkak oleh pesan info/debug di server sibuk. Ketiga, driver redis untuk session, queue, dan cache memisahkan beban tersebut dari database. Keempat, APP_URL wajib domain asli karena tautan verifikasi email dan aset dibangun dari nilai ini.

Strategi .env per Environment #

Setiap server menyimpan berkas .env-nya sendiri — berkas ini memang dikecualikan Git sejak instalasi pertama, jadi tidak pernah ikut terbawa antar mesin. Konsekuensinya, .env.example yang ter-commit harus selalu mencerminkan daftar kunci terbaru sebagai dokumentasi; rekan tim lain membangun .env lokal mereka dari berkas contoh tersebut. Untuk tim yang lebih besar, nilai rahasia seperti DB_PASSWORD lebih baik ditaruh di secrets manager (AWS Secrets Manager, Vault) dan diinjeksi sebagai environment variable asli sistem — Laravel membaca environment variable asli terlebih dahulu sebelum berkas .env, sehingga mekanisme ini bekerja tanpa mengubah kode.

config:cache Membekukan Nilai #

Deployment produksi dianjurkan menutup rangkaian dengan php artisan config:cache, sesuai dokumentasi deployment . Perintah ini menggabungkan seluruh berkas config/*.php menjadi satu berkas PHP di bootstrap/cache/config.php sehingga tidak ada ratusan env() dipanggil per request. Kita jalankan dan periksa hasilnya:

bash 
php artisan config:cache

Output yang Dihasilkan:

text 
   INFO  Configuration cached successfully.
bash 
ls -la bootstrap/cache/

Output yang Dihasilkan:

text 
total 64
-rw-rw-r--  1 z z   14 Sep 30 13:56 .gitignore
-rw-r--r--  1 z z 22411 Oct 13 22:17 config.php
-rwxrwxr-x  1 z z  963 Oct 13 22:17 packages.php
-rwxrwxr-x  1 z z 22575 Oct 13 22:17 services.php

Berkas config.php berukuran 22 KB itulah “bekuan” konfigurasi — nilai dari .env sudah dipanggang ke dalamnya. Isi barisnya bisa kita intip di sekitar konfigurasi aplikasi:

text 
138:    'name' => 'Laravel',
139:    'env' => 'local',
140:    'debug' => true,

Di sinilah jebakannya. Setelah config:cache berjalan, perubahan .env tidak lagi terbaca sampai cache dibangun ulang. Kita buktikan: ubah APP_NAME di .env menjadi "Toko Budi", lalu tanyakan nilai konfigurasi:

bash 
php artisan config:show app.name

Output yang Dihasilkan:

text 
  app.name ........................................................... Laravel

Nilai masih Laravel padahal .env sudah berubah — aplikasi membaca dari bekuan, bukan dari .env. Setelah cache dibersihkan, nilai baru langsung aktif:

bash 
php artisan config:clear

Output yang Dihasilkan:

text 
   INFO  Configuration cache cleared successfully.
bash 
php artisan config:show app.name

Output yang Dihasilkan:

text 
  app.name ......................................................... Toko Budi

Rotasi Secret Saat Deploy #

Alur deployment yang sehat memperlakukan rahasia sebagai siklus, bukan sekadar di-set sekali. Praktik yang dianjurkan: ganti APP_KEY dan kredensial layanan pihak ketiga setiap ada personel yang meninggalkan tim atau setiap insiden kecurigaan; jalankan rotasi pada jendela tenang karena data terenkripsi dengan kunci lama tidak bisa didekripsi oleh kunci baru; dan setelah rotasi selesai, bangun ulang cache konfigurasi (config:cache) agar bekuan tidak menyimpan kredensial usang.

Nilai environment kini beres dan terkunci dengan benar. Langkah berikutnya menghubungkan server web ke aplikasi: mengarahkan document root ke public/ dan menuliskan server block pertama kita di Web Server Configuration .