Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

What to do When Your Rails App Slug Size is Too Large for Heroku

DZone's Guide to

What to do When Your Rails App Slug Size is Too Large for Heroku

At General Assembly, we recently came across an interesting limitation in Heroku—the compiled slug size of applications can only be a maximum of 300MB. Read on to hear about the workaround we discovered.

· Cloud Zone
Free Resource

Site24x7 - Full stack It Infrastructure Monitoring from the cloud. Sign up for free trial.

At General Assembly, we recently came across an interesting limitation in Heroku—the compiled slug size of applications can only be a maximum of 300MB.

In our situation, because we have over a dozen campuses worldwide, we added a geolocation database to help showcase the most geographically relevant campus to our visitors.

Unfortunately, the database is almost 100MB by itself and pushed us over the edge of the Heroku slug size limit. We’re using Rails, so since we had a few high-resolution images in the Rails asset pipeline, our first reaction was to optimize the images using something like ImageOptim to see how much that would help reduce the slug size.

Interestingly, this didn’t make as large of an impact as we expected—particularly for PNG files, the compressed images were not that much smaller, and occasionally were larger than the originals! We then proceeded to move the images off to S3, but since we didn’t have that many to begin with, it didn’t free up 100 MB worth of space.

Next, Heroku helpfully suggested to use a .slugignore file to eliminate unnecessary files in the repository from being included in the slug. After adding the spec and app/assets folders to the .slugignore file, that only saved around 5 MB so we were still well over the limit.

Another area we took a good hard look at was our Gemfile, to see if there were any candidates for removal. Some solid wins were achieved by replacing therubyracer (clocking in at ~11MB) with node, as well as eliminating less-rails (also ~11MB) which we weren’t using. We also got rid of some instrumentation gems such as skylight that we didn’t need, saving another 20 MB or so. Having shaved down the slug size to around 301MB, we were so close, but still not quite under the limit…

Further digging discovered something very unusual: our staging slug was only 185 MB, drastically smaller than our production slug at 301MB, even though they contained the exact same codebase. It turns out that Heroku caches the build of each repository in the slug for faster processing on subsequent deploys.

However, this cache isn’t automatically cleared, but we were able to figure out how to do so manually. There’s a plugin for the Heroku command-line interface (CLI) for manipulating the Git repository on Heroku for your apps. We installed the plugin:

heroku plugins:install https://github.com/heroku/heroku-repo.git

And, then proceeded to purge the cache with the command:

heroku repo:purge_cache -a appname

This trick allowed us to finally get back down under the 300MB limit and continue deploying!

Site24x7 - Full stack It Infrastructure Monitoring from the cloud. Sign up for free trial.

Topics:
rails ,heroku

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}