Laravel deployment tools to deploy Laravel to production with zero downtime▋

What a Laravel deployment actually has to do

People say "deploy" like it is one action. It is really about a dozen, and they have to happen in a specific order, on a live machine, while real users are making requests. Skip one and you get a 500 page, or worse, a queue worker quietly running last week's code against this week's database schema.

Here is the real sequence. The new commit gets checked out into a fresh directory, usually something like releases/20260714093000, so the version currently serving traffic is untouched. Then composer install --no-dev --optimize-autoloader runs, along with whatever front end build you have (npm ci && npm run build). Your .env file is never in the repo, so it lives in a shared directory on the server and gets symlinked into the release. The same goes for storage/: user uploads, logs and framework caches must survive across deploys, so storage is a symlink to a shared path rather than a fresh empty folder every time. Get this wrong and every deploy silently deletes your uploads.

Next, database migrations with php artisan migrate --force. The --force flag is required because Laravel refuses to run migrations in production interactively. Then the caches get rebuilt: config:cache, route:cache, view:cache and event:cache. These turn your config and routes into a single compiled PHP file, which is a real performance win and also a real footgun, because a stale route cache will happily serve routes that no longer exist. This is exactly why the caches must be rebuilt in the new release, not carried over from the old one.

Then OPcache. PHP caches compiled bytecode keyed by file path, which is one of the underrated reasons atomic releases work so well: because each release lives at a new path, PHP sees new files rather than stale cached ones. If your setup uses a stable path or aggressive opcache.validate_timestamps=0 settings, the deploy needs to reset OPcache explicitly or you will serve old code from a new release and lose an hour to confusion.

Only now does the release get health checked. A request goes to the new code to confirm the app actually boots, the database is reachable and the caches compiled. If that check fails, the deploy stops and the old release keeps serving. If it passes, the current symlink flips to the new release directory and PHP-FPM reloads. The flip is a single atomic filesystem operation, which is the whole point: there is no moment where half the app is old and half is new.

Finally, php artisan queue:restart. Queue workers are long-running PHP processes that hold your application code in memory forever. If you do not restart them, they keep executing the previous release's code indefinitely. This is one of the most common Laravel deployment bugs, and it is nasty because the web app looks perfectly fine while the jobs behave strangely.

DeployManage runs all of that for you on every push, in that order, on every server in your fleet. The interesting part is not that it saves typing. It is that the sequence is identical every single time, including at 6pm on a Friday when someone is deploying a hotfix in a hurry.

Laravel deployment best practices

Most Laravel production incidents are not exotic. They come from the same short list of mistakes, and they are all avoidable.

• Use atomic releases, not git pull. Building into a new directory and flipping a symlink at the end is the single highest-value change you can make. It removes the window where a user hits your app mid-update.
• Keep .env and storage/ out of the release. Both belong in a shared directory that gets symlinked in. Secrets never go in the repo, and uploads must survive a deploy.
• Always run migrations with --force, and make them backward compatible. Deploy code that works with both the old and new schema, then clean up in a later release. Dropping a column in the same deploy that stops using it is how you take down the version still serving traffic.
• Never destroy data in a deploy. No migrate:fresh, no migrate:refresh, ever, on a production server. Take a database backup before a migration that alters real data.
• Rebuild the caches, do not reuse them. config:cache, route:cache, view:cache, event:cache. A stale route cache is a genuinely maddening bug to chase.
• Restart queue workers on every deploy. php artisan queue:restart tells workers to finish the current job and exit, and your process manager brings them back on the new code.
• Health check before you flip, not after. Verifying the release only once it is live means your users are the health check. Verify first.
• Make rollback a button, not a project. If rolling back requires thinking, you will not do it during an incident. You will try to fix forward while the site is down.
• Use composer install, not composer update. Production installs exactly what composer.lock says. Updating on the server means you deploy dependency versions nobody tested.
• Consider maintenance mode for risky migrations. For most deploys you do not need it. For a migration that rewrites a large table, php artisan down with a secret bypass URL is the honest call.
• Log every deploy. When something breaks at 3pm, the first useful question is always "what shipped, and when?" An audit trail answers it in seconds.

Laravel deployment checklist before you go live

Before a Laravel app takes its first real production traffic, walk this list. It takes twenty minutes and saves the kind of afternoon nobody enjoys.

• APP_ENV=production and APP_DEBUG=false. Debug mode on in production leaks your environment variables to anyone who triggers an exception. This is the most damaging misconfiguration in PHP, and it is a one-line fix.
• APP_KEY is set and backed up. Lose it and every encrypted value in your database becomes unreadable.
• HTTPS is enforced and the certificate auto-renews.
• A firewall is on, with only the ports you actually need open, and SSH is key-only.
• Database credentials are unique to the app, not a reused root user.
• Automated database backups exist, and you have restored one at least once. An untested backup is a rumor.
• Queue workers run under a process manager that restarts them if they die, and they get restarted on deploy.
• The Laravel scheduler is running (a single cron entry hitting schedule:run every minute) and you have confirmed a scheduled job actually fired.
• Error tracking and log aggregation are wired up. Production errors should reach you before a customer does.
• You have deployed to a staging environment with the same pipeline first. A deploy process you have never rehearsed is not a deploy process.
• You have practiced a rollback. Once. On purpose. Before you need it.

DeployManage covers a good chunk of this list by default: hardened servers with a firewall, SSL, managed MySQL and PostgreSQL, queue workers, the Laravel scheduler, and reusable provisioning recipes so server number nine comes up exactly like server number one. The rest is your app, and that part is your job.