Over a million developers have joined DZone.

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

Download the Essential Cloud Buyer’s Guide to learn important factors to consider before selecting a provider as well as buying criteria to help you make the best decision for your infrastructure needs, brought to you in partnership with Internap.

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!

The Cloud Zone is brought to you in partnership with Internap. Read Bare-Metal Cloud 101 to learn about bare-metal cloud and how it has emerged as a way to complement virtualized services.

rails ,heroku

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}