Bundler frozen "deployment mode" after a Gemfile Edit in CI
By Daniel Zoghalchali·Latchkey
You edited the Gemfile but did not regenerate Gemfile.lock, and CI runs with frozen (deployment) mode on. Frozen mode forbids changing the lockfile during install, so the mismatch is a hard failure rather than a silent re-resolve.
What this error means
bundle install fails after a Gemfile change, reporting that running in frozen/deployment mode it cannot update Gemfile.lock, and listing what you added or changed. The fix is to re-lock at the source, not in CI.
bundler output
The lockfile does not match the gemfile. Running in frozen mode, changes to
the Gemfile.lock are not allowed.
You have added to the Gemfile:
* gem "sidekiq"
Diagnose it: Ruby version and platform
Bundler resolves against the Ruby version and the platform recorded in the lockfile. A runner on a different Ruby or a Linux platform missing from Gemfile.lock fails in a way that names a gem rather than the cause.
Terminal
ruby -v && bundle -v
cat .ruby-version 2>/dev/null
bundle platform
# the usual CI-only failure: Linux platform absent from the lockfile
bundle lock --add-platform x86_64-linux
bundle install --jobs 4 --retry 3
Common causes
Gemfile edited without re-locking
A gem was added, removed, or bumped in the Gemfile but bundle was never re-run, so Gemfile.lock no longer matches. Frozen mode then refuses to proceed.
frozen / deployment enabled in CI
CI sets BUNDLE_FROZEN or --deployment, which pins the lockfile. This is intentional protection so drift fails loudly instead of being papered over.
How to fix it
Re-lock locally and commit
Regenerate the lockfile on a machine with network access, then commit it so CI has a matching lockfile.
On an ephemeral runner where you intend to re-resolve, turn frozen off for that job.
Terminal
bundle config set frozen false
bundle install
How to prevent it
Run bundle install after every Gemfile edit and commit the lockfile.
Add a bundle lock --check step to CI to catch drift in PRs.
Keep frozen mode on in CI so drift fails loudly.
Frequently asked questions
What causes Bundler frozen "deployment mode" after a gemfile edit in CI?
There are 2 common causes: gemfile edited without re-locking and frozen / deployment enabled in ci. A gem was added, removed, or bumped in the Gemfile but bundle was never re-run, so Gemfile.lock no longer matches.
How do I fix Bundler frozen "deployment mode" after a gemfile edit in CI?
There are 2 fixes depending on which cause you have: re-lock locally and commit and toggle frozen off only on a disposable runner. Work through them in order, since the first is the most common.
What does Bundler frozen "deployment mode" after a gemfile edit in CI actually mean?
bundle install fails after a Gemfile change, reporting that running in frozen/deployment mode it cannot update Gemfile.lock, and listing what you added or changed.
How do I stop Bundler frozen "deployment mode" after a gemfile edit in CI happening again?
Run bundle install after every Gemfile edit and commit the lockfile. The prevention section lists 3 changes that keep it from recurring.
