Going live with a Laravel application is exhilarating and terrifying in equal measure. You have spent weeks or months building features, writing tests, and refining the user experience. Now you need to make sure the production environment is ready to handle real users, real data, and real consequences.
This checklist is not theoretical. It is distilled from hundreds of Laravel deployments on Deploynix, from solo developer side projects to enterprise applications serving millions of requests. Not every item will apply to every application, but each one has prevented a production incident for someone.
Print this out. Pin it to your wall. Work through it methodically before every major launch.
Server Configuration (1-10)
1. Choose the right server size. Start with more resources than you think you need. Vertical scaling on Deploynix takes minutes, but running out of memory during your launch produces errors that are hard to debug under pressure. You can always scale down after you understand your real resource usage.
2. Set the correct timezone. Your server's timezone affects cron jobs, log timestamps, and scheduled tasks. Set it explicitly in your server configuration and in your Laravel config/app.php timezone setting. UTC is the safest default.
3. Configure swap space. Even well-provisioned servers can hit memory spikes. Swap space prevents the OOM killer from terminating your PHP processes during traffic bursts. Most Deploynix-provisioned servers include swap, but verify it is active.
4. Set appropriate file descriptor limits. PHP-FPM, Nginx, and your database all need file descriptors. The default limit on many Linux distributions is too low for production workloads. Deploynix configures this during provisioning, but verify with ulimit -n.
5. Configure PHP-FPM pool settings. The default pm.max_children value is almost certainly wrong for your server. Too low and requests queue up. Too high and your server runs out of memory. Calculate based on your server's available memory divided by the average memory per PHP process (typically 30-50 MB).
6. Set the correct PHP version. Deploynix supports multiple PHP versions. Make sure your server is running the version your application requires. Test with the exact same version in your CI pipeline.
7. Enable OPcache. OPcache caches compiled PHP bytecode, dramatically reducing CPU usage and response times. It should be enabled in production with appropriate settings for opcache.max_accelerated_files (Deploynix sets 20,000) and opcache.memory_consumption (Deploynix sets 256 MB).
8. Disable Xdebug. Xdebug is a development tool that slows PHP execution by 50-100%. It should never be installed on a production server. Deploynix does not install it by default, but verify if you have customized your server setup.
9. Configure Nginx worker processes. Set worker_processes to the number of CPU cores on your server. Deploynix handles this during provisioning, but if you have scaled your server, verify the setting matches your current CPU count.
10. Set up a firewall. Only expose ports that your application needs: 22 (SSH), 80 (HTTP), 443 (HTTPS), and any application-specific ports. Deploynix's firewall rule management makes this straightforward. Block everything else.
Application Configuration (11-20)
11. Set **APP_ENV=production.** This is obvious but still missed. Development and production environments behave differently in error reporting, caching, and debugging. Verify this is set correctly in your Deploynix environment variables.
12. Set **APP_DEBUG=false.** Leaving debug mode on in production exposes stack traces, environment variables, and database queries to anyone who triggers an error. This is a critical security issue, not just a best practice.
13. Generate a unique **APP_KEY.** Your application key encrypts sessions, cookies, and any data you encrypt with Laravel's encryption facilities. It must be unique to your production environment and never shared with development or staging. If it is compromised, rotate it immediately.
14. Set **APP_URL correctly.** This affects URL generation throughout your application. Include the scheme (https://) and do not include a trailing slash. Incorrect APP_URL causes broken links, incorrect redirects, and OAuth callback failures.
15. Configure your logging channel. The stack channel with daily and stderr drivers is a solid production default. Set LOG_LEVEL=warning or LOG_LEVEL=error to avoid filling your disk with informational messages. Monitor your log file sizes.
16. Run **php artisan config:cache.** This compiles all configuration files into a single cached file, reducing the number of file reads on every request. Run this as part of your Deploynix deploy script.
17. Run **php artisan route:cache.** Route caching can reduce route registration time from hundreds of milliseconds to single-digit milliseconds. This must be run after every deployment because cached routes become stale when you add or modify routes.
18. Run **php artisan view:cache.** Pre-compiles all Blade templates so they do not need to be compiled on the first request. This reduces response times for the first visitors after a deployment.
19. Run **php artisan event:cache.** Caches the event-to-listener mapping so Laravel does not need to scan your application for event listeners on every request.
20. Set **SESSION_DRIVER appropriately.** For a single server, file or database works. For multiple servers behind a load balancer, use redis (via Valkey on Deploynix) or database to ensure sessions are accessible from any server.
Database (21-28)
21. Use a dedicated Database server. Separating your database from your application server improves performance, allows independent scaling, and makes backups cleaner. Deploynix supports MySQL, MariaDB, and PostgreSQL on dedicated database servers.
22. Run migrations before going live. Execute php artisan migrate --force as part of your deployment process. The --force flag is required in production. Add this to your Deploynix deploy script.
23. Verify database indexes. Every WHERE clause and ORDER BY that appears in your application's queries should have a corresponding index. Missing indexes are the number one cause of slow database performance. Use EXPLAIN on your critical queries.
24. Configure connection pooling. Set DB_POOL and your database's max_connections appropriately. Too few connections and requests queue up. Too many and your database server runs out of memory.
25. Set up automated backups. Configure Deploynix's backup system to dump your database to AWS S3, DigitalOcean Spaces, Wasabi, or your chosen S3-compatible storage. Daily backups minimum, hourly for critical applications. Test your restore process before you need it.
26. Verify your database character set. Use utf8mb4 for MySQL and MariaDB to support emoji and all Unicode characters. This should be set in your database configuration and in your Laravel database.php config.
27. Disable database debugging in production. Ensure DB_LOG_QUERIES or any query logging middleware is disabled. Logging every query in production consumes memory and I/O.
28. Test your seeder data is not included. Development seeders should not run in production. Verify that your deploy script do not include php artisan db:seed unless you have production-specific seeders.
Security (29-36)
29. Force HTTPS everywhere. Set FORCE_HTTPS=true or configure your TrustProxies middleware. Deploynix auto-provisions SSL certificates for your domains. There is no excuse for serving production traffic over HTTP.
30. Configure CSRF protection. Verify that all non-GET routes are protected by CSRF middleware. Laravel enables this by default, but if you have excluded routes, verify the exclusions are intentional.
31. Set secure cookie flags. In production, set SESSION_SECURE_COOKIE=true to ensure session cookies are only transmitted over HTTPS. Set SESSION_HTTP_ONLY=true to prevent JavaScript access to session cookies.
32. Configure Content Security Policy headers. CSP headers prevent cross-site scripting by controlling which resources the browser is allowed to load. Start with a restrictive policy and loosen as needed.
33. Hide server version information. Configure Nginx to not reveal its version in response headers. Deploynix handles this in the Nginx configuration, but verify with a tool like curl -I.
34. Restrict SSH access. Use key-based authentication only. Disable password authentication. Deploynix enforces this during server provisioning. Restrict SSH access to specific IP addresses through Deploynix's firewall rules.
35. Audit your **.env file.** Verify that no development credentials, test API keys, or default passwords remain. Every secret should be production-appropriate. Do not use the same database password as your staging environment.
36. Review your API authentication. If your application exposes an API, verify that all endpoints require authentication unless explicitly public. Use Laravel Sanctum with appropriate token scopes. Rate limit all API endpoints.
Performance (37-42)
37. Configure a CDN for static assets. Serve your CSS, JavaScript, images, and fonts from a CDN. This reduces load on your server and improves load times for users worldwide. Configure the ASSET_URL in your Laravel environment.
38. Enable Gzip or Brotli compression. Nginx should compress text-based responses (HTML, CSS, JavaScript, JSON) before sending them to the client. This typically reduces transfer sizes by 60-80%. Deploynix's Nginx configuration includes compression by default.
39. Set appropriate cache headers. Static assets should have long cache lifetimes (one year) with versioned filenames. Laravel Mix and Vite handle versioning automatically. Dynamic pages should have appropriate Cache-Control headers.
40. Configure your queue worker. Use Deploynix daemons to run php artisan queue:work with appropriate --tries, --timeout, and --memory flags. For production, consider a dedicated Worker server to isolate queue processing from web request handling.
41. Pre-warm your caches. If your application relies on cached data (configuration, popular database queries, computed values), warm these caches before directing traffic to the server. Add cache warming to your deploy script.
42. Optimize Composer autoloader. Run composer install --optimize-autoloader --no-dev in production. The --optimize-autoloader flag generates a classmap for faster autoloading, and --no-dev excludes development dependencies.
Monitoring and Alerting (43-46)
43. Set up health checks. Configure a health check endpoint that verifies your application can connect to the database, cache, and any external services. Use an external uptime monitoring service to hit this endpoint regularly.
44. Configure error tracking. Use a service like Sentry, Flare, or Bugsnag to capture and aggregate exceptions. Laravel integrates with these services through their official packages. You need to know when errors occur, not discover them from user complaints.
45. Set up uptime monitoring. Monitor your application's availability from an external service. Deploynix's health alerts notify you when your server's resources are constrained, but external monitoring catches issues that internal monitoring cannot.
46. Monitor disk usage. Log files, uploaded files, and database growth can fill your disk. Set up alerts for when disk usage exceeds 80%. Deploynix's real-time monitoring shows current disk usage, and health alerts can notify you before it becomes critical.
DNS and SSL (47-50)
47. Configure DNS records correctly. Point your domain's A record to your server's IP address (or your Load Balancer's IP). Set appropriate TTL values: start with a short TTL (300 seconds) before launch so you can make changes quickly, then increase it (3600 seconds) once stable.
48. Verify SSL certificate provisioning. Deploynix auto-provisions SSL certificates, but verify the certificate is valid and covers all your domains (including www). Check the certificate expiry date and ensure auto-renewal is configured.
49. Set up DNS for email deliverability. If your application sends email, configure SPF, DKIM, and DMARC records. Without these, your transactional emails will land in spam folders. Your email provider will give you the specific records to add.
50. Test from multiple locations. Use DNS propagation tools to verify your DNS changes are visible worldwide. Test your application from different geographic locations and different devices. What works from your office might not work from your users' locations.
The Deploynix Advantage
If you are using Deploynix, many items on this checklist are handled automatically during server provisioning. PHP-FPM configuration, Nginx optimization, firewall rules, SSL provisioning, security hardening, and monitoring setup are all part of the provisioning process that completes in minutes.
Your deploy script handles the Laravel-specific optimizations: config caching, route caching, view caching, event caching, and Composer optimization. Zero-downtime deployment ensures your users never see a maintenance page during deployments.
Automated database backups, real-time health monitoring, and firewall management round out the operational concerns. But even with this automation, reviewing this checklist before a major launch ensures nothing falls through the cracks.
Conclusion
Going live is not a single event. It is a process that starts with this checklist and continues with ongoing monitoring, maintenance, and optimization. Work through these 50 items methodically. Do not skip items because they seem obvious. The obvious items are the ones most often missed.
Top comments (0)