Production Environment

Aplikasi yang lancar di laptop kita belum tentu berjalan di server produksi: environment-nya berbeda, dependency-nya harus dipangkas, dan setiap error akan dilihat pengguna asli. Chapter ini membahas apa yang membedakan lingkungan produksi, prasyarat server yang harus tersedia, serta langkah persiapan dependency dengan composer install --no-dev — semuanya kita buktikan dengan perintah yang benar-benar dijalankan. Setelah chapter ini, kita punya fondasi yang benar sebelum menyentuh konfigurasi environment dan web server.

Apa Arti “Production” #

Production adalah lingkungan tempat aplikasi melayani pengguna sungguhan. Tiga hal berubah sekaligus dibanding saat pengembangan: APP_ENV bernilai production, APP_DEBUG dimatikan agar detail error tidak bocor ke browser, dan seluruh konfigurasi dioptimalkan lewat cache. Kita bisa memeriksa status lingkungan dari artisan dengan memberi override environment lewat variabel di shell:

APP_ENV=production APP_DEBUG=false php artisan about --only=environment

Output yang Dihasilkan:

  Environment ................................................................  
  Application Name ................................................... Laravel  
  Laravel Version .................................................... 13.36.0  
  PHP Version .......................................................... 8.4.8  
  Composer Version .................................................... 2.10.3  
  Environment ..................................................... production  
  Debug Mode ............................................................. OFF  
  URL ......................................................... localhost:8000  
  Maintenance Mode ....................................................... OFF  
  Timezone ............................................................... UTC  
  Locale ....................................................................... en  

Perhatikan dua baris kunci: Environment ... production dan Debug Mode ... OFF. Nilai APP_ENV ini juga yang membuat perintah berbahaya seperti migrate meminta konfirmasi — perilaku yang kita bahas tuntas di Database Migration di Production . Sementara itu, alasan APP_DEBUG=false wajib sudah dibuktikan di Secure Configuration : halaman error versi debug membocorkan pesan exception, path file, hingga versi PHP.

Prasyarat Server #

Server produksi Laravel minimal menjalankan tiga komponen: web server (nginx atau Apache), PHP-FPM sebagai FastCGI process manager yang mengeksekusi kode PHP, dan Composer untuk memasang dependency. Kebutuhan ekstensi PHP bisa kita audit langsung dengan php -m. Berikut hasil nyata pada mesin uji:

php -m

Output yang Dihasilkan:

[PHP Modules]
bcmath
ctype
curl
dom
fileinfo
filter
json
mbstring
openssl
pcre
PDO
pdo_mysql
pdo_sqlite
Phar
sqlite3
tokenizer
xml
...

Daftar ekstensi wajib sesuai dokumentasi deployment Laravel — BCMath, Ctype, cURL, DOM, Fileinfo, JSON, Mbstring, OpenSSL, PCRE, PDO, Tokenizer, dan XML — semuanya tampil di output di atas, sehingga mesin ini lolos audit. Jika satu saja hilang, Composer akan menolak instalasi karena composer.json framework mendeklarasikan ekstensi tersebut sebagai platform requirement. Tambahkan ekstensi khas driver yang dipakai (pdo_mysql untuk MySQL, redis untuk Redis) sesuai arsitektur aplikasi.

composer install –no-dev #

Di server produksi, paket require-dev seperti PHPUnit, Faker, dan Collision tidak diperlukan — hanya memboroskan ruang disk dan memperlambat autoload. Kita pasang ulang dependency dalam mode produksi:

composer install --prefer-dist --optimize-autoloader --no-dev

Output yang Dihasilkan:

Installing dependencies from lock file
Verifying lock file contents can be installed on current platform.
Package operations: 0 installs, 0 updates, 33 removals
> Illuminate\Foundation\ComposerScripts::prePackageUninstall
  - Removing theseer/tokenizer (2.0.1)
  - Removing sebastian/version (6.0.1)
  - ...
54 packages you are using are looking for funding.
Use the `composer fund` command to find out more!

Tiga flag bekerja sama: --no-dev menghapus 33 paket pengembangan sesuai composer.lock, --prefer-dist memakai arsip distribusi alih-alih checkout Git, dan --optimize-autoloader membangun classmap sehingga autoloader tidak perlu memindai filesystem saat runtime. Efeknya terukur nyata pada direktori vendor:

Dependensi produksi menyusut 37% — transfer deployment lebih cepat dan permukaan serangan berkurang karena paket seperti PHPUnit yang pernah punya celah RCE tidak pernah terpasang di server.

OPcache #

Setiap request PHP membaca ratusan file framework dari disk dan mengompilasinya menjadi opcode. Ekstensi OPcache menyimpan hasil kompilasi itu di memori bersama, sehingga request berikutnya melewati tahap kompilasi. Ini optimasi paling murah dengan dampak terbesar — berikut konfigurasi tipikal untuk server produksi (contoh tampilan, dijalankan pada /etc/php/8.4/fpm/php.ini):

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=32
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0

Nilai validate_timestamps=0 berarti OPcache tidak lagi memeriksa perubahan file — kode baru hanya aktif setelah service PHP-FPM di-restart setelah deployment, perilaku yang justru kita inginkan agar rilis serempak.

Checklist Kesiapan Server #

Sebelum melanjutkan, pastikan seluruh butir berikut terpenuhi:

• PHP versi sesuai syarat composer.json beserta seluruh ekstensi wajib (php -m).
• Web server dan PHP-FPM terpasang dan saling terhubung lewat socket.
• Composer tersedia di server, composer install --no-dev berjalan mulus.
• OPcache aktif dengan konfigurasi produksi.
• Aplikasi bisa dinyatakan siap: APP_ENV=production, APP_DEBUG=false, php artisan about menampilkan Debug Mode OFF.

Dengan server yang siap, pekerjaan berikutnya bukan soal hardware melainkan soal isi file .env — nilai apa saja yang harus berubah, bagaimana strategi .env untuk banyak server, dan mengapa config:cache bisa membuat perubahan .env terasa “diabaikan”. Semua itu kita bahas di Environment Configuration .