Choosing the right version manager is often the first “real” challenge for a Ruby on Rails developer. It’s not just about installing the language; it’s about ensuring that your development environment matches your production server and that you can switch between legacy projects and the latest features without breaking your machine.
In this post, we’ll explore the main version managers in the ecosystem and a significant shift introduced in Rails 8 regarding environment consistency.
Why Use a Version Manager?
Ruby is an evolving language. Different projects often require different versions of Ruby and Rails. If you install Ruby directly through your operating system’s package manager (like apt or brew), you are stuck with one version, and you risk breaking system tools that rely on that specific version.
Version managers solve this by:
- Allowing multiple Ruby versions to coexist.
- Installing Gems separately for each Ruby version.
- Switching versions automatically when you enter a project folder.
The Main Contenders
1. mise (The Modern Speedster)
Formerly known as rtx, mise is the new community favorite. It is a drop-in replacement for asdf but written in Rust, making it significantly faster.
- Pros: Compatible with
asdfplugins and.tool-versions; manages Ruby, Node, and env vars; extremely fast. - Cons: Newer than others, but growing rapidly.
2. asdf (The Versatile Choice)
Until recently the gold standard for polyglot developers. asdf uses a plugin system to manage almost any runtime (Ruby, Node.js, PostgreSQL).
- Pros: One tool for your entire stack; uses a single
.tool-versionsfile. - Cons: Being replaced by
misedue to speed and ease of use.
3. rbenv (The Minimalist)
Lightweight and focused solely on Ruby. It works by using “shims” to intercept Ruby commands.
- Pros: Very stable; doesn’t interfere with your shell as much as others.
- Cons: Requires the
ruby-buildplugin to actually install new versions.
4. rvm (The Veteran)
The oldest and most feature-rich. It manages Ruby versions and “gemsets” (isolated silos for gems).
- Pros: Very powerful; handles everything out of the box.
- Cons: Overrides many shell commands, which can lead to conflicts with modern tools.
How it works: The .ruby-version File
Most version managers respect a file called .ruby-version placed in your project’s root directory. When you cd into the folder, the manager reads this file and switches the Ruby version for you automatically.
1
2
# .ruby-version
3.3.0
The Rails 8 Shift: Beyond the Version Manager
With the release of Rails 8, the conversation about version managers has shifted slightly. While you still need a way to install Ruby locally, Rails 8 doubles down on containerization as the primary way to manage environment consistency through Kamal and an improved Docker integration.
Dev Containers in Rails 8
Rails 8 makes it easier than ever to use Dev Containers. Instead of worrying if every developer on your team has the right version of mise or rbenv, Rails 8 provides a pre-configured .devcontainer folder.
- Standardized Environment: The Ruby version, database, and Redis are all defined in a Docker image.
- Zero-Setup: A new developer can clone the repo and open it in VS Code, and the entire environment is spun up inside a container.
Kamal: Moving to Production
Rails 8 uses Kamal by default for deployment. Kamal packages your app into a Docker image. This means that the version of Ruby you used in development is exactly the same one that goes to production, reducing the “it works on my machine” syndrome to zero.
If you are a modern developer working on multiple languages and want the best performance, mise is the current winner. If you prefer the classic, stable approach, rbenv remains a solid choice.
However, keep an eye on the Rails 8 philosophy: while version managers are great for your local shell, Docker and Dev Containers are becoming the standard for professional, reproducible development environments.