Using BUNDLE_FROZEN

Viewed 670

I often see the following line in Dockerfiles

ENV BUNDLE_FROZEN=true

I checked bundler docs and it says "Disallow changes to the Gemfile". But I'm confused why someone would want to disallow people to change Gemfile. After all we may add new gems as a project evolves. Could someone explain why we need this env var, how, and when we use it and why it is often appears in Dockerfiles?

1 Answers

This environment variable changes the behavior of bundler if it detects a difference between the Gemfile and the accompanying Gemfile.lock.

By default, when running bundle install, bundler will try to update the Gemfile.lock if there were any gems added or constraints changed. On production deployments, this is often undesirable since this may cause unexpected versions of gems to be installed which were not fully tested.

By setting BUNDLE_FROZEN=true, bundler will (1) require an existing Gemfile.lock and (2) will refuse to update this Gemfile.lock with updated information. This ensures that your production deployment only ever uses the exact gem versions locked into your commited Gemfile.lock.

The workflow here is that each time you add gems to your Gemfile, you would also run bundle install on your local box to update the Gemfile.lock. Afterwards, you can test the changes and commit the updated Gemfile.lock. When you later deploy your application, both files are in sync. With BUNDLE_FROZEN=true you can then be sure to use the exact environment in production as you have specified and tested during development.

In the end, this is basically a fail-safe to force you (and your colleagues) to actively update the Gemfile.lock after you changed the Gemfile or any dependencies. If you always do this already (and you are sure of that), you don't need to set BUNDLE_FROZEN in production. If you set it however, bundler will fail loudly if you forgot that rather than silently install gem versions you may not have fully tested.

Related