Add a Gemfile that names fastlane, commit both the Gemfile and Gemfile.lock, install with Bundler on CI, and run every lane through bundle exec. Then the automation that holds your signing and store credentials runs the exact gem versions you reviewed, and changes only when you run an update.
Why this matters
The release tool runs with your most sensitive credentials. If a new gem version arrives silently between two builds, you have changed code that can read the store key, with no review. A lockfile turns that into a visible diff.
What the documentation recommends
The fastlane setup guide recommends Bundler and a Gemfile to define the dependency on fastlane. It says this clearly defines the fastlane version and its dependencies and also speeds up execution. Its steps are:
- Install Bundler.
- Create a Gemfile with the RubyGems source and
gem "fastlane". - Run
bundle update, and add both the Gemfile and Gemfile.lock to version control. - Run fastlane with
bundle exec fastlaneand the lane name. - On CI, run
bundle installas the first build step. - To update fastlane, run
bundle update fastlane.
The same page says system Ruby is not recommended because dependencies can conflict, and that using sudo with gem installs often leads to permission trouble later. It also states supported Ruby versions, so check the current page when you pick one for CI.
What the lockfile gives you
| Without a lockfile | With a committed lockfile |
|---|---|
| Newest matching gems on each run | Same versions each run |
| A bad release can arrive unseen | Updates are a reviewed diff |
| Hard to say what ran for build 412 | The lockfile at that commit says |
The Ruby deployment guide adds that you should commit the Gemfile and Gemfile.lock, and install the bundle so the app uses the exact same gems as in development.
Update on purpose
Schedule a regular update, for example monthly, and do it in a branch:
- Run the update and read the changed lines in Gemfile.lock.
- Look up release notes for anything with a major version change.
- Run the beta lane against a test app first.
- Merge, and note the date.
If an advisory lands for a gem, you can update immediately and have a clear record of when.
Related pins in the pipeline
The tool is only one input. Pin the CI actions or plugins your workflow calls, pin the Xcode or JDK version, and keep Ruby on a managed version. Our post on fastlane Fastfile changes as code review covers the file that drives it all.
Audit the gems you run
Treat the lockfile as an inventory. Running a Ruby advisory check against it in CI catches known vulnerable gems. Our existing post on bundler lockfile practices is a good companion.
Try it yourself
Open the demo and look at how a lockfile turns into a component list with versions. That is what a pinned Gemfile.lock gives you for the release tool.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard scans dependency manifests and lockfiles, including your build tooling, to produce an SBOM and apply policy. Try a free scan.
Quick check
Is Homebrew install fine for fastlane?
The documentation lists it as an option, but Bundler gives you per-project version control and a lockfile, which is better for CI.
Should I commit Gemfile.lock?
Yes. The documentation says to add both the Gemfile and Gemfile.lock to version control.
Sources
Last reviewed: 19 October 2026.
