On a Mac, never build on the system Ruby; install a version manager and run your own current Ruby, because the pre-installed one is old, unpatched, and meant only for macOS's own scripts. The most common ruby mac mistake is treating /usr/bin/ruby as your development runtime. Apple ships that Ruby to support system scripting, it lags years behind, and on recent hardware Apple has stopped updating it meaningfully. Using it for real work means running an end-of-life interpreter with known, unpatched vulnerabilities.
Why the system Ruby is a security problem
The mac ruby that comes preinstalled lives in /usr/bin/ruby. Check yours:
/usr/bin/ruby --version
On many Macs this reports Ruby 2.6, a version that reached end of life and no longer receives security patches. EOL interpreters accumulate known CVEs in the runtime and its bundled libraries, and nothing will fix them. Running production-adjacent code, or even installing gems, on an EOL Ruby is the kind of finding a dependency or configuration audit flags immediately.
Do not try to upgrade or remove the system Ruby. macOS depends on it, System Integrity Protection guards it, and deleting it can break OS behavior. Leave it exactly where it is and install a separate, current Ruby that you control.
Use a version manager, not a raw install
The right way to update ruby version on a mac, including M1, is a version manager. It installs Rubies into your home directory, keeps them isolated from the system, and lets you switch per project. The two solid choices in 2025 are rbenv and mise.
rbenv is the long-standing default and pairs naturally with Homebrew:
brew install rbenv ruby-build
rbenv init
# add the printed line to your ~/.zshrc, then restart the shell
mise (formerly rtx) is a faster, Rust-based manager that handles Ruby, Node, Python, and more from one tool. If you are a Rails developer who also needs Node, mise removes the juggling:
brew install mise
echo 'eval "$(mise activate zsh)"' >> ~/.zshrc
Either way, the principle is the same: your Rubies now live under your control and get updated on your schedule, not Apple's.
Installing a current Ruby
With rbenv, list what is available and install a current stable release:
rbenv install -l # list installable versions
rbenv install 3.3.3 # pick a current stable version
rbenv global 3.3.3 # set it as your default
ruby --version # confirm you are off the system Ruby
The final check matters. If ruby --version still reports the old system version, your shell's PATH is not picking up the shim; make sure the rbenv init line is in your shell profile and that you have opened a fresh terminal.
For a per-project pin, drop a .ruby-version file in the project root so everyone on the team, and your CI, runs the same interpreter:
rbenv local 3.3.3
Apple Silicon (M1, M2, M3) specifics
Updating ruby to a current version on Apple Silicon is straightforward for modern Rubies but painful for old ones. People searching how to "update ruby to 2.7" or set a Ruby version on M1 hit a wall: older releases like 2.7.0 often fail to compile on Apple Silicon because of OpenSSL and other C-library incompatibilities.
The fix is usually to stop targeting the ancient version. If a project genuinely requires 2.7, you will likely need to pin a compatible OpenSSL and pass build flags:
brew install openssl@1.1
RUBY_CONFIGURE_OPTS="--with-openssl-dir=$(brew --prefix openssl@1.1)" \
rbenv install 2.7.8
But treat that as life support, not a destination. Ruby 2.7 is itself past end of life. The security-minded move is to get the application onto a supported Ruby (3.1 or newer) so you are not fighting the toolchain to run an interpreter that no longer gets fixes anyway.
Keep gems and Ruby patched over time
Installing a current Ruby once is not the finish line. Two ongoing habits keep a ruby mac setup healthy:
- Track EOL. Check a source like endoflife.date periodically and move up before your Ruby line stops receiving security releases. Patch-level updates within a supported line (for example 3.3.x) are low-risk and worth doing promptly.
- Scan your gems. The interpreter is one thing; your
Gemfile.lockis the larger attack surface. Runbundle auditor an SCA tool in CI so a vulnerable gem fails the build instead of shipping quietly.
Done this way, updating Ruby on your Mac is a ten-minute task that takes you off an unpatched EOL runtime and onto something you can keep current. The only real trap is the one at the start: mistaking Apple's system Ruby for your own.
FAQ
Should I update or delete the system Ruby on my Mac?
Neither. The system Ruby in /usr/bin exists for macOS's own scripts and is protected by System Integrity Protection. Leave it in place and install a separate, current Ruby with a version manager like rbenv or mise that you use for development.
How do I update my Ruby version on a Mac M1?
Install rbenv or mise via Homebrew, then rbenv install a current stable version (such as 3.3.x) and set it globally. Modern Rubies build cleanly on Apple Silicon; only old EOL versions like 2.7 need special OpenSSL build flags, and those are better avoided.
Can I install Ruby 2.7 on Apple Silicon?
You can, but it often needs a pinned openssl@1.1 and custom configure options because 2.7 predates good Apple Silicon support. Since Ruby 2.7 is end of life, the better answer is usually to migrate the project to a supported Ruby 3.x rather than keep an unpatched version alive.
Which Ruby version manager should I use?
rbenv is the reliable default and integrates well with Homebrew. mise is a faster alternative that also manages Node, Python, and other runtimes, which helps if you work across multiple languages. Both isolate your Rubies from the system version.