Zero-Downtime Deployments for a Laravel Monolith

Zero-downtime deployment gets treated as something a hosting provider or a checkbox in a CI config provides. It's actually a set of application-level decisions that have to be made deliberately, because the deploy tooling can't fix a migration that locks a table your app still needs mid-deploy.

• Migrations must be backwards-compatible with the currently running code — add nullable columns before the code that requires them ships.
• Symlink-based atomic releases (or a blue-green deploy) so traffic switches instantly between a fully-built old and new release.
• Sessions and queued jobs must survive a deploy — don't store session data only in memory on a single app server.
• Run a health check against the new release before switching traffic to it, not after.

None of this requires exotic infrastructure. It requires treating every migration as a two-step operation — expand, then later contract — and never assuming old and new code won't briefly run side by side, because during a real deploy, they will.

Zero-downtime isn't a deploy tool feature. It's what happens when you assume old and new code run together, briefly, and design for it.