# RVM: Managing Ruby Versions with the Ruby enVironment Manager

> RVM installs Ruby interpreters, keeps them isolated from each other, and switches between them per shell or per project directory. Here is how the mechanism works, how to install it, and where it stops being the right tool.

**rvm/rvm** — Ruby enVironment Manager (RVM)

- Repository: https://github.com/rvm/rvm
- Website: https://rvm.io
- Stars: 5,188 · Forks: 1,046
- Language: Shell
- License: NOASSERTION
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/rvm-rvm

## What RVM actually manages

RVM stands for Ruby enVironment Manager. The README describes it as a tool that "manages Ruby application environments and enables switching between them." That sentence covers two distinct jobs. The first is installing interpreters: RVM can fetch and build MRI ruby, JRuby, Rubinius, TruffleRuby, mruby, IronRuby, MacRuby, Maglev, Opal and Topaz, plus the historical Ruby Enterprise Edition, which the README notes is no longer developed by its authors but can still be installed. The second job is isolation: each installed interpreter lives in its own directory tree, and RVM exposes commands to move a shell session or a project directory from one to another. The audience is anyone who has to run code against more than one Ruby on the same machine, whether that is a developer testing a gem against 2.3 and 3.x, or a build host that needs JRuby alongside MRI. It is not a package manager for gems in the Bundler sense, and it is not a container runtime. It is a shell-level tool that rewrites your PATH and defines functions in your interactive shell.

## How switching works: shell functions and .ruby-version

The mechanism is worth understanding before you install anything, because it explains most of the errors people hit. RVM is distributed as shell scripts, and after installation it hooks into your shell profile so that `rvm` is a shell function rather than an external binary. That is why the well-known error message says "Rvm is not a function, selecting rubies with 'rvm use ...' will not work": the function was never loaded into the current shell, usually because the profile was edited after the shell started or because a non-interactive shell does not source it. When you run `rvm use INTERPRETER[-VERSION]`, the function rewrites PATH so that the selected interpreter's bin directory comes first, along with its associated gem and wrapper paths. The README also documents a directory-level trigger: placing a `.ruby-version` file in a project folder causes an automatic switch to the selected Ruby whenever you enter that folder, which depends on the same shell hooking being active. Two special interpreter names exist for `use`: `default`, which resolves to the default Ruby or the system Ruby if none has been set, and `system`, which means the state before RVM was installed. That `system` option is the escape hatch when you want to confirm whether a problem belongs to RVM or to the machine.

## Installing RVM and installing your first Ruby

The README splits installation by platform. On Ubuntu it points to a dedicated package repository at https://github.com/rvm/ubuntu_rvm, and notes that a newer version can be obtained afterwards through the upgrade command. On any other operating system, the prerequisites are `curl` and `gpg2`, and the install is a single piped script. The `-s stable` argument selects the stable channel and is passed through to the script rather than to bash itself.

```bash
curl -sSL https://get.rvm.io | bash -s stable
```

After this runs, the installer modifies your shell profile so the `rvm` function is available in new shells. Open a new terminal before continuing, otherwise the next command will fail with the not-a-function error. To confirm the tool is loaded and see which interpreters are already installed, the README's command set includes listing commands, and `rvm help COMMAND` prints details for any subcommand.

Installing an interpreter uses `rvm install INTERPRETER[-VERSION] OPTIONS`. The README states that when no version is given, RVM installs the latest stable version of the selected interpreter, and when the interpreter is omitted, RVM assumes MRI ruby. Its own example shows that these four commands are equivalent:

```bash
rvm install ruby-2.3.1
rvm install ruby-2.3
rvm install 2.3.1
rvm install 2.3
```

Adding `--default` to the install command makes that Ruby the default for future shells. To move the current shell onto it, use `rvm use` with the same interpreter and version syntax that `install` accepts.

## Upgrading RVM itself, and why the channel matters

RVM upgrades itself, which is unusual for a version manager and has practical consequences. The command is `rvm get VERSION`, where VERSION is one of three forms documented in the README: `stable` for the latest stable RVM, described as good for servers; `master` for the latest development code, described as possibly unstable; and `branch /path/branch` for a branch, intended for testing new features or bug fixes. The README's issue-reporting section explicitly asks users to run `rvm get master` and retry before filing a bug, on the grounds that the fix may already exist in the development branch. That is a candid admission of the project's release rhythm: the tagged releases and the branch diverge. The repository's most recent listed release is 1.29.12, published on 2021-01-15, while the last push to master was on 2026-09-15. Anyone who pins to a release tag is running code that predates years of branch work; anyone who runs `rvm get master` is running code the README itself declines to call stable. There is no third channel in between that the documentation describes.

## Where RVM is the wrong tool

The design that makes RVM capable is also what makes it intrusive. It edits your shell profile, defines functions, and changes PATH globally, so debugging a problem means reasoning about shell state as much as about Ruby. In CI images and containers that start non-interactive shells, the function hook is not loaded by default, and `rvm use` fails in exactly the way the common error message describes. For that reason the repository ships a Dockerfile that installs RVM inside a Fedora 37 image, copies the checkout to /rvm, runs `./install`, appends a colored prompt to ~/.bashrc, and drops into bash. That file is explicitly described in its own comment as useful "to try changes in RVM without affecting the local system", not as a production pattern. A second limitation is scope: RVM manages Ruby interpreters, not the gems inside them, beyond the gemset concept, so it does not replace Bundler and does not solve native extension build failures, which depend on system headers and compilers. Finally, the README does not document a rollback path for `rvm get`, so if an upgrade leaves your shell broken, recovery means reinstalling or checking out a different branch rather than reverting a transaction.

## RVM versus rbenv: two different bets

The most common comparison is with rbenv, and the difference is architectural rather than cosmetic. rbenv uses shim binaries: it places a directory of small wrappers early in PATH, and each wrapper resolves the intended Ruby at call time by reading version files. It does not define an `rvm use`-style shell function that mutates the environment, and it does not install Ruby itself by default; the ruby-build plugin is a separate component. RVM takes the opposite approach. It installs interpreters into its own tree, defines shell functions, and rewrites PATH when you switch. The practical consequences follow directly: RVM's model fits an interactive developer machine where you want one command to install an interpreter and another to switch to it, including interpreters like JRuby and TruffleRuby that the README lists as supported. rbenv's model fits environments where shell mutation is awkward, such as scripts and non-interactive CI steps, because resolution happens per process rather than per shell session. Neither is strictly better; they fail in different places. RVM fails when the shell hook is missing. rbenv fails when you expect it to build and install an interpreter for you without ruby-build.

## Licence, contribution terms and upgrade cost

The repository metadata reports the licence as NOASSERTION, which means GitHub could not classify it automatically. The README is more specific: the contributing section states that "any and all contributions offered in any form, past present or future are understood to be in complete agreement and acceptance with our Apache License v2.0", and links to the LICENSE file in the repository root. The precise terms therefore need to be read from that file rather than inferred from the metadata label. On upgrade cost, the self-updating design means there is no dependency lockfile to bump; the cost is instead operational. Because `rvm get stable` and `rvm get master` point at different code, two machines that both claim to run RVM can be running very different implementations, and the version string alone will not tell you which. The README's issue template asks reporters to split each command and its output into its own fenced code block and to redirect verbose output with `>` when there is a lot of debug or trace output, which suggests the maintainers expect environment-specific diagnosis rather than reproducible version-pinned reports. Budget for that: an upgrade that breaks a shell profile is fixed by reinstalling, and the project's own guidance is to try the development branch first.

## Conclusion

Adopt RVM if you need to install and switch between many Ruby interpreters, including JRuby, TruffleRuby or mruby, on a single machine, and if you are comfortable with a shell-function-based tool that modifies your shell profile. Do not adopt it if you want a small, single-purpose version switcher, or if you depend on tagged releases: the newest release listed in the repository is 1.29.12 from 2021-01-15, while the last push to master was on 2026-09-15, so the stable channel and the development branch have diverged for years. Before committing, verify that the install script works on your distribution, check what the installer appends to your shell profile, and read the LICENSE file, since the repository metadata reports NOASSERTION while the README states contributions are accepted under the Apache License v2.0.

## FAQ

### What does RVM stand for?

RVM is the acronym of Ruby enVironment Manager. The README describes it as a tool that manages Ruby application environments and enables switching between them.

### What does RVM mean in a text?

In this project's context the letters expand to Ruby enVironment Manager, the name given in the README. It refers to the tool that installs Ruby interpreters and switches between them.

### What is the purpose of RVM?

It installs Ruby interpreters such as MRI ruby, JRuby, Rubinius and TruffleRuby, and lets you switch between them per shell or per project directory. The README frames the two jobs as managing Ruby application environments and enabling switching between them.

### Is RVM still maintained?

The repository is not archived and the last push to master was on 2026-09-15, so the branch is still receiving commits. The most recent listed release is 1.29.12 from 2021-01-15, so the tagged stable channel and the development branch are far apart.

## Sources

- [Issues](https://github.com/rvm/rvm/issues)
- [Project website](https://rvm.io)
- [README](https://github.com/rvm/rvm/blob/master/README.md)
- [Releases](https://github.com/rvm/rvm/releases)
- [rvm/rvm on GitHub](https://github.com/rvm/rvm)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rvm-rvm