Maintenance mode

Maintenance mode answers every visitor with a holding page and a 503.

​

Nginx serves it, not the application

This is the part worth knowing. Nginx answers the 503, not the framework. That means it reads the same on a WordPress install or a static build as it does on a Laravel application, and it goes on working when the release behind it will not boot — which is exactly when you most want a holding page. It also means it is not artisan down. The application is still running. Queue workers keep working, scheduled jobs keep firing, and anything reaching the application by a route other than nginx is unaffected. The page itself lives under nginx’s own directory rather than in the site’s document root, because the release is replaced on every deploy and can be missing entirely when one has failed.

​

The bypass link

The first thing anybody does after taking a site down is try to look at it. While maintenance is on, the panel shows a link that gets you past your own holding page: open it once and you keep browsing the site normally. It is rotated every time the site goes down, so a link pasted into a chat during one outage is not still a way in during the next. It stops working when maintenance ends. It is shown in full rather than behind a copy button — anybody who can read that page can already turn maintenance off outright, so the secret protects the site from the internet rather than from them.

​

Deploying while down

Deploys still run. Taking a site down and then deploying the change that needed it down is the ordinary order of events. A deploy never lifts maintenance. Nothing in the deployment touches the flag, which is what makes maintenance survive a deploy by construction rather than by anybody remembering to preserve it. The deployment output says so at the end, so a release that looks live to you and is invisible to everybody else is not a surprise. Coming back up is a separate decision, made after you have looked at the new release through the bypass link. The HTTP check carries the bypass header, so a deploy into a site under maintenance is still checked properly rather than rolling itself back because everything answers 503.