Bundler's Install, Update, and Exec Commands
Fast recall
Quick revision
Core answer
bundle install makes the machine match the Gemfile and current lockfile, resolving only when the declarations require it. bundle update GEM intentionally unlocks and re-resolves that gem plus necessary dependencies within allowed ranges; bundle update without names may move the whole allowed graph. bundle exec COMMAND runs an executable inside the locked bundle so a different globally installed gem version cannot be activated. Install reproduces, update changes, and exec activates.Whether you know Bundler reads the Gemfile, installs with bundle install, writes Gemfile.lock, and runs with bundle exec to load exact versions.
Running without bundle exec (loads system gems, not the locked versions), or committing code without Gemfile.lock.
Bundler reads the Gemfile, installs with bundle install, writes Gemfile.lock (exact versions). Run with bundle exec to load those versions; solves 'works on my machine'.
Interview-ready guide
Interview answer
The three commands serve different stages of dependency management. bundle install is the normal setup and synchronization command. With a current lockfile it installs the recorded versions; after a Gemfile change it tries to satisfy the new declaration while preserving locked gems that do not need to move.
bundle update is an intentional version-changing operation. bundle update rack unlocks Rack and any dependencies that must be reconsidered, but still obeys the Gemfile's version requirements. Running it without gem names can update the entire graph to the newest versions those requirements allow.
For example, if a security fix is released for one HTTP gem, I update that gem by name, inspect the Gemfile.lock diff, run the suite, and commit the changed lockfile. I do not delete the lockfile or update everything unless a broader upgrade is the actual task.
bundle exec rspec is not an installer. It launches RSpec with the executables and gems from the current bundle activated. Without that boundary, a command found on the machine can use a global version that differs from the project's resolved version. A generated binstub such as bin/rspec can provide the same bundle-scoped convenience.
A simple memory rule is: install reproduces the chosen environment, update deliberately changes it, and exec runs inside it. Keeping those intentions separate makes dependency changes small enough to review and test.
Bundler's Install, Update, and Exec Commands
Direct Answer
bundle install makes the machine match the Gemfile and current lockfile, resolving only when the declarations require it. bundle update GEM intentionally unlocks and re-resolves that gem plus necessary dependencies within allowed ranges; bundle update without names may move the whole allowed graph. bundle exec COMMAND runs an executable inside the locked bundle so a different globally installed gem version cannot be activated. Install reproduces, update changes, and exec activates.
Deep Dive & Architecture
The lockfile is Bundler's starting solution. Installation checks that it still satisfies the Gemfile and current platform, then obtains missing gems without looking for unrelated upgrades. This makes a fresh checkout predictable instead of time-dependent.
An update relaxes selected locked choices so the resolver can choose newer allowed versions. Transitive dependencies may also change because the selected gem declares a different range. A targeted command limits the search area but does not promise a one-line lockfile diff, so review remains necessary.
Execution has a separate problem: RubyGems may know about several installed versions. Bundler setup restricts activation to the resolved graph. bundle exec establishes that environment before loading an executable, preventing a globally installed command from selecting incompatible libraries.
CI and deployment should fail when the declared and locked state disagree rather than silently create a new production-only resolution. Updating belongs in a reviewed development change; installing and executing belong in repeatable automation.
Code Example
bundle install
bundle outdated rack
bundle update rack
git diff -- Gemfile.lock
bundle exec ruby -Itest test/rack_adapter_test.rb
# Commit the reviewed lockfile change with the tested upgrade.
Common Mistakes & Pitfalls
Running without bundle exec (loads system gems, not the locked versions), or committing code without Gemfile.lock.
Check your understanding
Answer these without looking back at the article.
- Can a targeted update change transitive dependencies too?
- Why is deleting `Gemfile.lock` a poor routine update strategy?
- What problem does `bundle exec` prevent?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.