We haven't got into adding the cache control headers for static assets yet. We also allow friendly urls with '.' in them so any users deciding to call themselves 'theoooo.php' would get caught out with the anti bot measures you've taken. Quick way to get rid of those pesky requests otherwise though!

If anyone is interested we deploy our sites using Chef, and I'm happy to make the recipes we use for that public as well.

theoooo, you suggested that @503 location should be replaced with try_files $uri /system/maintenance.html @passenger;

while that surely works, it returns maintenance page with HTTP 200, and that means that search bots might index such page (or treat it as a valid site response anyway, if noindex is mentioned in the page code). I also noticed that some browsers ignore no-cache in the page content, and serve locally cached page even when the server content has been updated - thus leaving users with maintenance page instead of a functional service till they do a proper reload of the page.

Using HTTP 503 solves these problems, and also RFC 2616 suggests HTTP 503 code to be used code for servers in maintenance state.

Hey just found this gist, and I've learned a lot from it. Thanks for sharing.
Can I still use something like the following, if my Rails app is using full page caching to the file system? The files get written out with the .html extension.

We recently moved to Nginx+Unicorn due to some passenger's segmentation faults.
You can try passenger in standalone mode, but compile mod_rails module inside is not recommended now.
Anyway, nginx upstream module help you in both cases: 1) use Unicorn, 2) use Standalone Passenger.