Belajar Laravel #22: Deployment — Persiapan Pindah dari Lokal ke Server

Di episode #21 saya sudah menyentuh perintah optimize dan eager loading. Kali ini semua itu dipakai nyata: memindahkan aplikasi Laravel dari mesin lokal ke server beneran. Ini bagian yang paling saya tunda-tunda, karena satu salah langkah bisa bikin error 500 yang bikin bingung jam dua pagi. Ini yang saya catat soal persiapan deployment.

Satu File yang Menentukan Semua: .env

Pelajaran pertama saya: file .env yang dipakai di lokal TIDAK boleh disalin mentah ke server. Di lokal biasanya APP_DEBUG=true supaya error tampil detail, tetapi di server itu justru berbahaya — stack trace Laravel memperlihatkan isi variabel environment, nama file konfigurasi, sampai kredensial database. Selain itu URL aplikasi juga berbeda, jadi APP_URL harus ikut disesuaikan.

# di server produksi
APP_ENV=production
APP_DEBUG=false
APP_URL=https://domain-anda.com
DB_HOST=127.0.0.1

Ini berarti bagi saya: konfigurasi tidak lagi ditulis di kode, tapi dipindah ke environment. Prinsip yang sama akan saya pakai lagi nanti untuk API key dan secret token — semuanya tidak boleh ada di repository.

Jangan Pindahkan Folder vendor

Kesalahan yang hampir saya lakukan: meng-zip seluruh folder proyek di lokal lalu diunggah utuh. Folder vendor berisi dependensi Composer yang sudah terpasang dengan versi dan platform lokal — di server bisa saja versi PHP-nya beda. Jalur yang benar adalah unggah kode sumber saja, lalu pasang ulang dependensi di server dengan mode produksi.

composer install --no-dev --optimize-autoloader
php artisan key:generate        # hanya kalau APP_KEY kosong
php artisan migrate --force     # --force wajib di production
php artisan optimize            # config, route, dan view cache sekaligus

Perintah php artisan optimize adalah kelanjutan dari pembahasan cache di episode sebelumnya: konfigurasi dan daftar route dibaca sekali lalu disimpan, bukan di-parse ulang tiap request. Yang membuat saya sempat bingung, setelah mengedit .env atau route di server, perintah itu harus dijalankan ulang — kalau tidak, perubahan tidak terbaca karena file cache-nya masih yang lama.

Izin Folder dan Queue

Yang paling sering bikin error bukan kodenya, tapi izin tulis. Proses upload, penulisan log, dan penyimpanan cache dikerjakan oleh web server (biasanya user www-data), bukan user yang dipakai saat SSH. Kalau folder storage dan bootstrap/cache tidak bisa ditulis, Laravel langsung lempar exception.

sudo chown -R www-data:www-data storage bootstrap/cache
sudo chmod -R 775 storage bootstrap/cache

Kalau aplikasi memakai queue (episode #16) dan scheduler (episode #17), keduanya juga harus hidup di server: satu proses worker dijalankan terus-menerus, dan satu entri cron schedule:run per menit. Saya menyadari ini hanya setelah email notifikasi tidak pernah terkirim padahal di lokal lancar — worker queue-nya memang tidak pernah dinyalakan.

Shared Hosting atau VPS?

Pertanyaan yang paling sering muncul saat saya mencari referensi. Untuk belajar dan proyek kecil, keputusan saya sendiri sederhana: pilih yang sesuai dengan hal yang mau saya pelajari sekarang.

Aspek	Shared hosting	VPS
Setup	Panel siap pakai, tanpa urus server	Install PHP, web server, dan database sendiri
Biaya	Umumnya lebih murah di awal	Bulanan, naik ikut kebutuhan
Kontrol	Terbatas; cron dan modul kadang dibatasi	Penuh; versi PHP bebas dipilih
Cocok untuk	Belajar, blog, proyek ringan	Aplikasi dengan queue, scheduler, dan trafik naik

Yang saya catat: proses deployment-nya sendiri tidak jauh beda — yang berbeda hanya siapa yang mengurus servernya. Konsep .env, optimize, izin folder, dan worker tetap sama di keduanya.

Checklist Sebelum Angkat Jempol

• APP_ENV=production dan APP_DEBUG=false sudah di-set.
• Dependency dipasang ulang dengan --no-dev, bukan disalin dari lokal.
• php artisan migrate --force dan php artisan optimize sudah dijalankan.
• Folder storage dan bootstrap/cache bisa ditulis web server.
• Satu entri cron schedule:run dan worker queue aktif kalau dipakai.
• HTTPS aktif, dan file .env tidak ikut ter-commit ke repository.

Deployment bukan momen menegangkan kalau urutannya jelas: konfigurasi dulu, dependensi, izin, baru proses latar belakang. Setelah checklist di atas beres, barulah saya lanjut ke episode berikutnya tentang paket populer yang bisa dipakai tanpa menulis ulang dari nol.

Sumber

• laravel.com/docs — Deployment
• laravel.com/docs — Configuration
• getcomposer.org — Composer install
• laravel.com/docs — Task Scheduling