A developer deploys Laravel to a VPS "identical to local." The .env file is copied with APP_DEBUG=true, the queue stays on the sync driver, there is no scheduler, and storage/ is not writable. The machine is fine. The production environment is not. Laravel forces a clear split between hardware and application configuration — otherwise every deploy becomes a lottery.
The confusion keeps showing up in support tickets: you buy a "Laravel-ready" server because PHP 8.3 is installed, then forget to cache routes and views, start workers, or lock down permissions. The server runs code; the environment decides whether it runs in demo mode or production. Until you read those two maps separately, incidents look like application bugs when they are deployment mistakes.
Server and environment: two different maps
The server covers the operating system, nginx or Apache, PHP-FPM, optional Redis, and security patches. The environment covers .env, APP_KEY, database URLs, mail settings, the queue driver, and Laravel caches (config:cache, route:cache, view:cache). The build layer adds composer install --no-dev and Vite or Mix compilation. The runtime layer adds supervised workers and the cron line that calls schedule:run every minute.
| Layer | Examples | Common mistake |
|---|---|---|
| Server | nginx, PHP-FPM 8.2, Redis | Assuming installed PHP = production-ready |
| Environment | .env, APP_KEY, QUEUE | Staging .env copied live |
| Build | Composer without dev, compiled assets | Dev dependencies in production |
| Runtime | workers, scheduler | Jobs on sync, missing cron |
A Laravel-ready server with bad configuration is still a demo Laravel app.
A deployment checklist that holds up
Environment variables must show APP_ENV=production, APP_DEBUG=false, unique keys, and correct URLs. Dependencies go through composer install --no-dev --optimize-autoloader. Front assets are built in CI or locally then deployed; php artisan storage:link creates the expected symlink. After each deploy, regenerate config, route, and view caches. Directories storage/ and bootstrap/cache/ must be writable by the PHP-FPM user.
Queues need Supervisor or systemd with Redis or a dedicated table; watch failed_jobs. The scheduler needs a cron entry * php artisan schedule:run. Migrations run with migrate --force only after a database backup. Each step can be automated — Forge, Envoyer, GitHub Actions, Deployer — but the list stays the same whether you click or script.
Choosing a host beyond CPU
A credible Laravel host offers recent PHP, documented extensions, installable or managed Redis, SSH, reliable cron, and a zero-downtime path — release symlink or rolling deploy if traffic is critical. A minimal staging environment with a separate .env avoids surprises. Shared hosting can work for small apps; once queues and workers matter, VPS or managed platform becomes the norm.
Align PHP version with Choosing a PHP version and dependencies with Composer in production. Octane and Horizon add useful complexity only after FPM bottlenecks or Redis queue dashboards are proven necessary.
The climax: a successful deploy is invisible
Browse PHP hosts in our directory and compare plans with Redis and SSH via the comparator.
Decide and move forward without blind spots
Version a .env.production template without secrets and inject keys through your pipeline or secrets manager. Automate deploy with documented cache, migration, and worker restart steps. Configure Supervisor for queues and test rollback to the previous release before the first real incident. Monitor failed_jobs and application logs from day one. Finally, confirm the scheduler actually runs — a missing cron often shows up three weeks later when reports stop sending.
Frequently asked questions
What is the difference between server and Laravel environment?
The server is the machine — OS, web server, PHP version. The environment is the application context: .env file, APP_ENV=production, config caches, and API keys. Mixing them up leads to APP_DEBUG=true in production or staging keys going live.
FPM or Laravel Octane in production?
PHP-FPM remains the robust default. Octane with Swoole or RoadRunner can win on high-traffic APIs but adds package compatibility constraints. Start with FPM unless benchmarks prove otherwise.
How should Laravel queues be managed?
Supervisor or systemd must keep queue:work or queue:listen running. Use Redis or a database queue — never the sync driver in production for mail and heavy jobs.
What should you ask a host for Laravel?
PHP 8.2 or newer, Composer, Redis, reliable cron, SSH access, useful extensions (intl, bcmath, pcntl for workers), and a documented zero-downtime deploy path.
In Laravel, production starts when .env says production — not when DNS points to the VPS.