Yes. The ruby-lang.org branches page marks Ruby 3.2 with status "eol" and an end date of 1 April 2026. Ruby 3.3 is in security maintenance, with end of life expected on 31 March 2027. If a service still runs 3.2, record it as unsupported and plan the move.
What the branches page lists
The Ruby maintenance branches page lists a status and dates for each series. As we read it on 19 October 2026:
| Series | Status | Normal maintenance until | End of life |
|---|---|---|---|
| 3.3 | Security maintenance | 1 April 2026 | 31 March 2027 (expected) |
| 3.2 | EOL | 1 April 2025 | 1 April 2026 |
| 3.1 | EOL | 1 April 2024 | 26 March 2025 |
| 3.0 | EOL | 1 April 2023 | 23 April 2024 |
The page also lists newer series. The word "expected" on the 3.3 date matters: a date that is expected can move, so do not treat it as a contract.
Why Ruby is more than one version number
A Ruby application has at least three version facts, and they can each age at a different speed.
- The interpreter. The ruby binary in your image or host.
- The framework. For example Rails, whose maintenance policy has its own bug fix and security windows. See Rails maintenance policy explained.
- The gems. Hundreds of libraries, each with its own maintainers and release rhythm.
A Gemfile can declare a ruby version line, and a Gemfile.lock pins the gem versions that were resolved. The ruby line tells you what the project asks for. It does not prove what is installed on the server. Compare it with the image or host value, as described in declared, built and running.
An upgrade path that holds up
- Read the Rails and gem support matrix for your target Ruby. Some gems lag a new Ruby by months.
- Update gems first on the current Ruby, so the later jump is smaller.
- Run the suite on the target Ruby in CI as a separate job. Treat new warnings as work items.
- Move one minor version at a time. Skipping several makes failures harder to attribute.
- Deploy to a small slice of traffic and watch error rates before full rollout.
Run a vulnerable gem check at each step, since upgrades change what resolves. Bundler audit in CI is covered in run bundler-audit in CI.
What to log
| Field | Example |
|---|---|
| Interpreter and version | Ruby 3.2.x |
| Status | End of life per ruby-lang.org |
| Source and check date | Branches page, 19 October 2026 |
| Owner and target | Team, migration date |
| Exposure | Internet-facing or internal |
If the service must stay a while, add the compensating steps you actually have, such as network limits and a short deploy cycle for gem fixes, and a date to revisit.
Try it yourself
Click through it at your own pace, or open it full screen. Find where package versions are shown, since a gem list and an interpreter version belong in the same inventory.
Where Safeguard fits
Safeguard's dependency scanning reads your lockfile into an SBOM, and reachability analysis helps separate gem vulnerabilities your code can actually call from the rest. A free scan is at gold.safeguard.sh/scan.
Quick check
Is Ruby 3.3 supported right now?
It is in security maintenance on the branches page, with end of life expected on 31 March 2027.
Does bundler audit cover the interpreter?
No. It checks gems. Track the interpreter separately.
Sources
Last reviewed: 19 October 2026.
