Ruby: Installation Articles

Understanding Ruby Installation Methods

Ruby can be installed in several ways, and the method you choose decides what you can do later: whether two projects can run on two different Ruby versions, whether an operating system update can replace your interpreter without warning, and whether features such as the YJIT compiler are available in the build you end up with.

Our recommendation for a new setup is a version manager, and the one we use throughout the site is Mise. Install Ruby: A Step-By-Step Guide covers the whole process (build dependencies, installation and version switching) and a companion article explains why the system Ruby on macOS should be left alone. The sections below compare the alternatives.

Native Package Managers

Homebrew on macOS and APT on Debian-based distributions install Ruby with a single command, and that is the fastest route to a working interpreter.

A package manager gives you one Ruby, installed system-wide, on the version its maintainers decided to ship (often several releases behind on APT). Upgrading the package upgrades your Ruby, and gems installed into a system path tend to require sudo and break across those upgrades.

Where the package managers are indispensable is the layer underneath. The Xcode command line tools or build-essential, plus libraries such as OpenSSL, libyaml and libffi, are what any Ruby build needs to compile. Use the package manager for the dependencies, and a version manager for Ruby itself.

Source Compilation

Building Ruby from the official source gives full control over the build: which compiler and flags are used, which optional libraries are linked, and whether extras are compiled in. YJIT, for example, needs a Rust toolchain present at build time.

Doing it by hand means running configure, make and make install yourself, tracking where each version landed, and repeating all of it on every release. That is rarely worth it, because version managers compile from source anyway: Mise builds Ruby with ruby-build, the same script rbenv uses. You get an interpreter compiled for your machine without maintaining the process yourself. Manual builds are for the unusual cases (a patched interpreter, an unsupported platform, or working on Ruby itself).

Version Managers

A version manager installs Ruby versions under your home directory and switches between them per project, so nothing lands in a system path and no sudo is involved. A .ruby-version file in the repository is enough for the right interpreter to be selected when you enter the directory.

The differences between them are mostly mechanical. rbenv works through shims, small wrapper scripts placed ahead of everything else in your PATH. Mise adjusts the environment directly when you enter a directory, manages languages other than Ruby, and reads both .ruby-version and its own mise.toml. asdf takes a similar multi-language approach with shims, and chruby is deliberately minimal, leaving installation to ruby-install.

All of them do the job. We use Mise, which is also the manager the official Rails guides install, but a project already set up with rbenv does not need fixing: these are alternatives to each other, not layers to stack.

Windows Considerations

Ruby does run natively on Windows. RubyInstaller bundles the interpreter with an MSYS2 toolchain so gems with C extensions can be compiled, and for plain Ruby scripting that is enough.

The friction shows up around Rails. Native gems, database clients and background tooling are built and tested against Linux first, and paths, permissions and case sensitivity behave differently. Windows Subsystem for Linux (WSL) sidesteps all of it by giving you a real Linux environment alongside your Windows applications, matching the Linux servers most Ruby applications are deployed to. The Windows section of our installation guide covers enabling it, and from there the Linux instructions apply unchanged.

Choosing the Right Method

Three questions settle it in practice:

  • Do you need more than one Ruby version? As soon as there is a second project, you do. That rules out package-manager installs and points to a version manager.
  • Do you need control over the build? A version manager already compiles from source. Only an unusual requirement justifies doing it by hand.
  • Are you developing on Windows? Ruby tooling targets Unix-like systems first. WSL gives you the environment the Linux servers most Ruby applications run on, without leaving Windows.

For almost every setup those answers converge on the same place: a version manager on macOS, Linux or WSL, with the package manager supplying the build dependencies.