Table of Contents
By Khimananda Oli | Last reviewed: August 2026
Deploying a framework without a structured verification process is the primary cause of post-release outages and performance regressions in PHP applications. This Laravel production deployment checklist consolidates fifteen years of infrastructure experience into actionable steps that prevent common failures related to permissions, caching, and queue management. Before you push your next release, use this guide to ensure your environment matches the rigorous standards required for business-critical workloads.
How do you prepare the server environment for a Laravel production deployment checklist?
The foundation of any stable application lies in the operating system and web server configuration. In my experience auditing deployments across Nepal and global clients, most "application bugs" are actually misconfigured infrastructure. Start by securing the base OS; follow a guide on securing a fresh VPS to disable root login, configure UFW, and set up fail2ban before installing a single PHP package.
Nginx and PHP-FPM Configuration
Your Nginx configuration must explicitly pass requests to PHP-FPM via a Unix socket rather than TCP for local performance. Ensure the fastcgi_param SCRIPT_FILENAME points to the correct public index path. A common mistake in 2026 is forgetting to increase client_max_body_size for file uploads or failing to set real_ip_header when behind Cloudflare or an AWS ALB, which breaks rate limiting and logging.
<!-- /etc/nginx/sites-available/laravel -->
server {
listen 80;
listen [::]:80;
server_name example.com;
return 301 https://$server_name$request_uri;
}
server {
listen 443 ssl http2;
server_name example.com;
root /var/www/html/public;
index index.php;
location / {
try_files $uri $uri/ /index.php?$query_string;
}
location ~ \.php$ {
fastcgi_pass unix:/var/run/php/php8.4-fpm.sock;
fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
include fastcgi_params;
}
}File Permissions and Ownership
Incorrect permissions are a top security vulnerability. The web server user (www-data) should own the storage and bootstrap/cache directories, but never the entire application root. Use the following commands during every deployment to reset ownership safely:
chown -R www-data:www-data storage bootstrap/cachefind storage -type d -exec chmod 775 {} \;find storage -type f -exec chmod 664 {} \;- Ensure the deployment user is in the
www-datagroup to avoid permission conflicts during CI/CD.
Which application optimizations belong in a Laravel production deployment checklist?
Development environments prioritize debuggability; production demands speed. You must compile all configuration, routes, and views into cached files. This reduces filesystem I/O and eliminates parsing overhead on every request. If you are running containers, review containerizing Laravel apps to ensure these caches are built during the image build stage, not at runtime entrypoint.
| Optimization | Command | Impact | Risk if Skipped |
|---|---|---|---|
| Config Cache | php artisan config:cache | ~20% faster boot | Env vars ignored at runtime |
| Route Cache | php artisan route:cache | Significant routing speedup | Closure-based routes break |
| View Cache | php artisan view:cache | Eliminates Blade compilation | High CPU on first hits |
| Event Cache | php artisan event:cache | Faster event discovery | Minor overhead per request |
| Composer Autoload | composer dump-autoload -o | Class map optimization | Slower class resolution |
A critical warning: route:cache does not support closure-based routes. Audit your routes/web.php and routes/api.php files before enabling this. Convert any closures to controller actions. Also, remember that once config:cache is active, the .env file is completely ignored. All environment variables must be referenced via env() only inside config files, never directly in controllers or services.
How do you manage queues and scheduled tasks in production?
Queues are non-negotiable for modern Laravel applications handling emails, notifications, or heavy processing. Relying on the default sync driver in production will block HTTP requests and degrade user experience. Configure Redis as your queue driver for persistence and visibility timeout control. For detailed tuning, see Laravel queues and background processing.
Supervisor Configuration
Never run queue:work manually in a terminal session. Use Supervisor to keep workers alive and automatically restart them when they hit memory limits or after deployments. Below is a battle-tested configuration for 2026:
[program:laravel-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/html/artisan queue:work redis --sleep=3 --tries=3 --max-time=3600 --memory=256
autostart=true
autorestart=true
stopasgroup=true
killasgroup=true
user=www-data
numprocs=4
redirect_stderr=true
stdout_logfile=/var/log/laravel-worker.log
stopwaitsecs=3600The --max-time=3600 flag ensures workers gracefully exit after one hour, allowing Supervisor to spawn fresh processes. This prevents memory leaks from accumulating over days of uptime. Always run supervisorctl reread && supervisorctl update after changing configs.
Scheduler Daemon
Since Laravel 11+, the scheduler daemon (schedule:run every minute) has been replaced by a long-running schedule:work command in many setups, though cron remains valid. If using the daemon approach, manage it via Supervisor similarly to queue workers. Verify timezone settings in config/app.php match your server's system time to prevent tasks firing at unexpected hours—a frequent issue in Nepal where servers may default to UTC while business logic expects NPT.
What security and monitoring steps finalize a Laravel production deployment checklist?
Security is not a feature; it is the baseline. After configuring the application, you must harden the transport layer and validate headers. Obtain certificates via Let's Encrypt or your cloud provider's ACM. Follow this SSL setup guide if managing certificates manually. Enable HSTS, X-Content-Type-Options, and Referrer-Policy headers in Nginx, not just in middleware, for defense-in-depth.
Observability and Error Tracking
You cannot fix what you cannot see. Integrate Sentry, Flare, or Datadog before going live. Configure log channels to separate application errors from access logs. Set up alerts for queue failures, high error rates, and disk usage. In regulated environments, ensure log retention meets compliance requirements (e.g., 90 days for SOC 2). Verify that sensitive data like passwords or tokens are never written to logs by auditing your exception handlers.
Database and Backup Verification
Test your backup restoration process, not just the backup creation. A backup you cannot restore is worthless. Schedule automated snapshots of RDS or EC2 volumes. For self-managed databases, verify replication lag and connection pool sizing. Run php artisan migrate --force only after confirming migrations are backward-compatible with the previous code version to support zero-downtime deployments.
Finalizing Your Laravel Production Deployment Checklist
A disciplined Laravel production deployment checklist transforms chaotic releases into predictable, auditable events. By systematically verifying server configuration, enforcing caching, managing queues with Supervisor, and validating security controls, you eliminate entire categories of production incidents. Infrastructure is code, and deployment is a pipeline—treat both with engineering rigor. If your team needs help establishing audit-ready deployment workflows or optimizing existing Laravel infrastructure, reach out to discuss your architecture.
