config.assets.compile=true in Rails production, wh

Question

The default Rails app installed by rails new has config.assets.compile = false in production.

And the ordinary way to do things is to run rake assets:precompile before deploying your app, to make sure all asset pipeline assets are compiled.

So what happens if I set config.assets.compile = true in production?

I wont' need to run precompile anymore. What I believe will happen is the first time an asset is requested, it will be compiled. This will be a performance hit that first time (and it means you generally need a js runtime in production to do it). But other than these downsides, after the asset was lazily compiled, I think all subsequent access to that asset will have no performance hit, the app's performance will be exactly the same as with precompiled assets after this initial first-hit lazy compilation. is this true?

Is there anything I'm missing? Any other reasons not to set config.assets.compile = true in production? If I've got a JS runtime in production, and am willing to take the tradeoff of degraded performance for the first access of an asset, in return for not having to run precompile, does this make sense?

Answer 1

Because it is opening a directory traversal vulnerability - https://blog.heroku.com/rails-asset-pipeline-vulnerability

Answer 2

Set config.asset.compile = false

Add to your Gemfile

group :assets do gem 'turbo-sprockets-rails3' end

Install the bundle

Run rake assets:precompile

Then Start your server

Answer 3

From the official guide:

On the first request the assets are compiled and cached as outlined in development above, and the manifest names used in the helpers are altered to include the MD5 hash.

Sprockets also sets the Cache-Control HTTP header to max-age=31536000. This signals all caches between your server and the client browser that this content (the file served) can be cached for 1 year. The effect of this is to reduce the number of requests for this asset from your server; the asset has a good chance of being in the local browser cache or some intermediate cache.

This mode uses more memory, performs poorer than the default and is not recommended.

Also, precompile step is not trouble at all if you use Capistrano for your deploys. It takes care of it for you. You just run

cap deploy

or (depending on your setup)

cap production deploy

and you're all set. If you still don't use it, I highly recommend checking it out.

Answer 4

For anyone using Heroku:

If you deploy to Herkou, it will do the precompile for you automatically during the deploy if compiled assets are not included (i.e. public/assets not committed) so no need for config.assets.compile = true, or to commit the precompiled assets.

Heroku's docs are here. A CDN is recommended to remove the load on the dyno resource.

Answer 5

To have less overhead with Pre-compiling thing.

Precompile everything initially with these settings in production.rb
# Precompile *all* assets, except those that start with underscore
config.assets.precompile << /(^[^_\/]|\/[^_])[^\/]*$/

you can then simply use images and stylesheets as as "/assets/stylesheet.css" in *.html.erb or "/assets/web.png"

Answer 6

It won't be the same as precompiling, even after that first hit: because the files aren't written to the filesystem they can't be served directly by the web server. Some ruby code will always be involved, even if it just reads a cache entry.