As iGEL and Anlek Consulting pointed out in the comments, it’s good practice to send a 503 Service Temporarily Unavailable HTTP code back to the client. A normal user won’t notice the difference, but spiders do. Sending the 503 code will tell search engines, like Google, that your site is not available and that they should not re-index your maintenance message as the new site content. Instead, they’ll come back later when your site returns a HTTP 200 code again.

You can try this fairly easily by putting your site in maintenance mode (per the instructions that follow) and do a HEAD request:

Use Capistrano

Now, you can run (from your own machine):

cap deploy:web:disable

This task will upload a generic placeholder and place it in public/system/maintenance.html. If nginx sees this file exists, it will render it and abort further processing. So, as long as the maintenance.html file is present, your app is not accessible.

When you’re migrations are done, you can run:

cap deploy:web:enable

This will have remove the maintenance.html file, and thus making your app accessible again.

Piecing it all together

What you probably want is a separate task to deploy new code and run migrations. Here’s the task I used:

Note that you can use the environment variables REASON and UNTIL to give some info about why the app is down.

Keep in mind that when you put up the maintenance.html none of your files is accessible. This includes stylesheets and js files. Make sure to host any images and other assets on a remote server like Amazon S3.

My site is free of ads and trackers. I record privacy-respecting usage statistics with
Fathom.