Deploying Laravel in 2026: Forge, Envoyer, and Zero-Downtime Deploys

Deploying Laravel in 2026 is a solved problem — as long as you pick one of the well-worn paths and respect a handful of rules that have not changed in a decade: run the optimization commands, restart your workers, migrate carefully, and never let users see a half-deployed application. This post maps the realistic options, from a Forge-managed VPS to the shared-hosting cPanel account you sometimes inherit, and the deploy mechanics that apply to all of them.

The anatomy of every good Laravel deploy

Whatever the infrastructure, a correct deploy performs the same sequence:

composer install --no-dev --optimize-autoloader
php artisan migrate --force
php artisan config:cache
php artisan route:cache
php artisan view:cache
php artisan event:cache
php artisan queue:restart   # or horizon:terminate

Two of these are chronically forgotten. The cache commands must run on every deploy, because a stale config cache will happily serve last week\'s settings. And the queue restart is non-negotiable: workers are long-lived processes holding the previous release\'s code in memory, so until they cycle, your queued jobs run old logic against new database schema — a category of bug that is miserable to diagnose. queue:restart and horizon:terminate both finish the current job gracefully before exiting, and your process supervisor brings the workers back on fresh code.

Frontend assets deserve one decision made early: build them in CI or during deploy (npm ci && npm run build) and ship the compiled output — never commit builds to the repo, and never run dev servers in production.

Forge: the default answer for VPS hosting

Laravel Forge remains the path of least resistance for teams running on DigitalOcean, Hetzner, AWS, or any plain Ubuntu server. Forge provisions the entire stack — Nginx, PHP-FPM, MySQL or PostgreSQL, Redis, scheduler cron, daemon supervision for queue workers — and wires up push-to-deploy from your Git provider. The things you would otherwise hand-configure and eventually misconfigure (TLS via Let\'s Encrypt, firewall rules, PHP version upgrades, deployment scripts) become dashboard toggles.

Forge\'s standard deployment updates code in place: git pull, composer install, the artisan commands. For most applications that window of a few seconds is acceptable, especially combined with the built-in ability to put the app into maintenance mode with php artisan down --refresh=15 --secret="bypass-token", which lets your team keep browsing while users see a polite retry page. When even seconds matter, you step up to atomic deploys.

Zero-downtime: the Envoyer model

Envoyer — and self-hosted equivalents like Deployer — implement the atomic release pattern. Each deploy builds a complete new release in its own directory; a symlink flip makes it live:

/var/www/app
├── releases/
│   ├── 20260703121500/
│   └── 20260706093000/   # new release, fully built
├── storage/               # shared across releases
├── .env                   # shared across releases
└── current -> releases/20260706093000

Nginx serves current/public, and because a symlink swap is atomic at the filesystem level, no request ever sees a partially deployed application. If the new release misbehaves, rollback is another symlink flip — seconds, not a re-deploy. The shared storage directory and .env are symlinked into each release so uploads and configuration survive across deploys. Envoyer layers on the operational comforts: health checks after activation, deployment hooks at each phase, heartbeat monitoring for your scheduler, and coordinated deploys across multiple servers. One caveat worth knowing: with PHP-FPM, opcache keeps serving old file paths after the flip, so atomic setups reload FPM or use cachetool in the activation hook.

Do not forget the human half of zero-downtime: migrations must be backward compatible for the seconds (or, with queued jobs, minutes) that old code runs against the new schema. Add columns as nullable, backfill, then tighten; split destructive changes (dropping or renaming columns) into a later deploy after no running code references them. The expand-and-contract pattern is what makes "zero downtime" true in practice rather than just on the web tier.

Containers and platforms

Teams standardized on containers have first-party support too: a Dockerfile running PHP-FPM behind Nginx, or FrankenPHP/Octane images for single-binary simplicity, deployed to anything from a bare VPS to Kubernetes. Laravel Cloud, the first-party managed platform, pushes further in the other direction — fully managed infrastructure with autoscaling and hibernation where you deploy the repo and skip server thinking entirely. The trade-off matrix is stable: managed platforms buy you time, containers buy you portability, Forge-style VPS buys you the most capability per dollar with modest ops effort.

Shared hosting: the unfashionable reality

Plenty of real Laravel work still lands on cPanel shared hosting — client budgets are what they are. It works, with honest constraints. You typically get no SSH-level process supervisor, so Horizon and long-running queue:work daemons are out; the workable pattern is cron-driven: one cron entry running php artisan schedule:run every minute, and queued work handled by queue:work --stop-when-empty on a frequent cron, or simply the sync driver for low-traffic apps. Structurally, never place the whole repo in public_html — deploy the app above the webroot and point the document root (or a symlink) at the public directory so .env and storage are not web-accessible. Deploys are usually Git pulls via SSH where offered, or CI-built artifacts pushed over SFTP. It will never be zero-downtime, but a cached, queue-light Laravel app serves modest traffic from shared hosting perfectly respectably.

A pre-launch checklist that catches the classics

1. APP_ENV=production, APP_DEBUG=false, real APP_URL.
2. HTTPS forced, and the cron entry for schedule:run actually present (scheduled jobs silently not running is the most common post-launch discovery).
3. Queue workers supervised and restarted on deploy; failed-job notifications wired to Slack or mail.
4. Logs shipped somewhere (daily driver at minimum, a log service ideally) and error tracking installed.
5. Database backups scheduled and restore-tested — an untested backup is a hope, not a plan.
6. Health endpoint (/up) behind an uptime monitor.

Closing thoughts

The deployment story in 2026 rewards boring choices. Forge plus Envoyer (or Deployer) covers the vast majority of Laravel applications with push-to-deploy, atomic releases, and rollbacks measured in seconds; containers and Laravel Cloud serve the teams that need their particular trade-offs; and even shared hosting remains viable when you respect its limits. The failures that actually hurt are rarely infrastructure-exotic — they are a forgotten queue:restart, a destructive migration, or a missing cron line. Automate the sequence once, put it in version control, and deploys become the least interesting part of your week. That is the goal.