---
title: "How fast can you actually patch Ruby?"
slug: how-fast-can-you-actually-patch-ruby
url: https://listedarticles.com/articles/how-fast-can-you-actually-patch-ruby
canonical_url: https://paagman.dev/how-fast-can-you-patch-ruby/
content_type: blog_post
language: en
published_at: 2026-10-26T23:00:00.000Z
updated_at: 2026-10-28T23:10:50.684Z
author: "Dennis Paagman"
authored_by: human
publisher: "Paagman.dev"
publisher_url: https://paagman.dev/
topics: ["Ruby", "Security", "DevOps"]
license: all-rights-reserved
word_count: 1344
reading_minutes: 6
citation: "Dennis Paagman, Paagman.dev. \"How fast can you actually patch Ruby?.\" 26 Oct 2026. https://paagman.dev/how-fast-can-you-patch-ruby/ (all-rights-reserved)"
# The full text follows. The web page shows an extract and sends readers
# to the source above; quote the citation and link the canonical URL.
---

# How fast can you actually patch Ruby?

> After waiting on the Docker community image to deploy the Ruby 4.0.9 security release (fixing GitLab-found regexp CVEs), Dennis Paagman measures how long the release took to reach installers, version managers, system packages, container images, CI and hosting platforms, from minutes for ruby-build and the Ruby core team's rubylang/ruby image to nearly 16 hours for the far more popular ruby image.

*Dennis Paagman · Paagman.dev · October 27, 2026 (updated October 28, 2026)*

When I tried to update an app to [Ruby 4.0.9](https://www.ruby-lang.org/en/news/2026/10/23/regexp-fixes-for-gitlab-cves/) last Friday, the official Docker community image wasn’t available yet. The release fixed vulnerabilities GitLab had found, but I had to wait before I could deploy.

A few months ago, a government Rails site was [hit by an ActiveStorage vulnerability](https://rietta.com/blog/ruby-on-rails-cve-exploited-hours-after-patch/) eight hours after the patch went out. Last week, [PHP2Shell](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/) was being exploited *before* it was announced.[1](#fn:php2shell) Waiting for a Docker image can eat up the time you have to respond.

## When Ruby 4.0.9 became available

I took every installer and version manager listed on the [official installation page on ruby-lang.org](https://www.ruby-lang.org/en/documentation/installation/), then added container images, CI providers and hosting platforms I could think of. For each, I checked when 4.0.9 became available.[2](#fn:times)

All times start when the **Ruby 4.0.9 source tarball became available**, on **Friday 23 October 2026, 04:04 UTC**.[3](#fn:tag)

### Installers and version managers

| Resource | Available after |
| --- | --- |
| [ruby-build](https://github.com/rbenv/ruby-build/releases/tag/v20261023) (rbenv, and mise when compiling) | 43 m |
| [ruby/ruby-builder binaries](https://github.com/ruby/ruby-builder/releases/tag/ruby-4.0.9) | 48 m |
| [Homebrew ruby-build](https://github.com/Homebrew/homebrew-core/pull/320592) | 1 h 10 m |
| [asdf](https://github.com/asdf-vm/asdf-ruby/commit/83edf4358e773317ac200ce751874d3ec147f2e7) | 2 h 43 m |
| [jdx/ruby binaries](https://github.com/jdx/ruby/releases/tag/4.0.9) (mise’s precompiled Rubies) | 8 h 15 m |
| [RubyInstaller](https://github.com/oneclick/rubyinstaller2/releases/tag/RubyInstaller-4.0.9-1) (Windows, also RVM 4 Windows) | ⚠️ 16 h 35 m |
| [RVM](https://github.com/rvm/rvm/commit/4660dfc85e76686d9461455d2081d1884c226003) | ⚠️ 18 h 34 m |
| [rv](https://github.com/spinel-coop/rv-ruby/releases/tag/20261023) | ⚠️ 21 h 40 m |
| [ruby-install](https://github.com/postmodern/ruby-versions/commit/19a204db5575bc0109905bfbea0d3777948d3517) | ⚠️ 5 d 10 h 46 m[4](#fn:ruby-install) |
| [chruby](https://github.com/postmodern/chruby) | Depends on the installer used[5](#fn:chruby) |
| [rbenv for Windows](https://github.com/RubyMetric/rbenv-for-windows) | ❌ last updated to 4.0.1 in March |

### Container images

| Resource | Available after |
| --- | --- |
| [rubylang/ruby](https://hub.docker.com/r/rubylang/ruby/tags?name=4.0.9) (by the Ruby core team) | 8 m |
| [bitnami/ruby](https://github.com/bitnami/containers/commit/6fb7b88e5c3c9210dc40a49503f9bd2085168676) | 1 h 59 m |
| [rails/devcontainer](https://github.com/rails/devcontainer/pkgs/container/devcontainer%2Fimages%2Fruby) (Rails dev container images) | 9 h 34 m |
| [ruby](https://github.com/docker-library/official-images/pull/22575) (by the Docker community) | ⚠️ 15 h 57 m |

### CI

| Resource | Available after |
| --- | --- |
| [GitHub Actions setup-ruby](https://github.com/ruby/setup-ruby/releases/tag/v1.334.0) (Linux/macOS) | 1 h 12 m |
| [CircleCI cimg/ruby](https://github.com/CircleCI-Public/cimg-ruby/pull/245) | 1 h 36 m |
| [GitHub Actions setup-ruby](https://github.com/ruby/setup-ruby/releases/tag/v1.335.0) (Windows) | ⚠️ 28 h 34 m |

### Hosting platforms

| Resource | Available after |
| --- | --- |
| [Heroku](https://devcenter.heroku.com/changelog-items/3850) | 2 h 28 m |
| [DigitalOcean App Platform](https://docs.digitalocean.com/products/app-platform/reference/buildpacks/ruby/) (uses Heroku’s buildpack) | 2 h 28 m[6](#fn:digitalocean) |
| [Railway](https://github.com/jdx/ruby/releases/tag/4.0.9) (uses mise) | 8 h 15 m |
| Fly.io, Kamal and anything else using the official Docker community image | ⚠️ 15 h 57 m |
| [Google Cloud](https://console.cloud.google.com/artifacts/docker/serverless-runtimes/us/runtimes-ubuntu2404/ruby/sha256:02a6f25828b8d42918b9683e777a3edc8b660a647bc257d41d090ca9f4588fbe) (Cloud Run, App Engine) | ⚠️ ≈ 3 d 14 h, default still 4.0.7 |
| [AWS Elastic Beanstalk](https://docs.aws.amazon.com/elasticbeanstalk/latest/relnotes/release-2026-10-27-al2023.html) | ⚠️ 4 d 4 h 07 m |
| [AWS Lambda](https://github.com/aws/aws-lambda-base-images/commit/2d1844bc7ad5525a67175e61aaccadfe93a413c1) | ⚠️ 4 d 16 h 29 m |

### System packages

| Resource | Available after |
| --- | --- |
| [Snap](https://snapcraft.io/ruby) | 7 m |
| [Homebrew](https://github.com/Homebrew/homebrew-core/pull/320602) | 2 h 41 m |
| [nixpkgs](https://github.com/NixOS/nixpkgs/pull/577241) | 3 h 47 m |
| [Fedora](https://bodhi.fedoraproject.org/updates/FEDORA-2026-4b2e500f14) (Rawhide; [44](https://bodhi.fedoraproject.org/updates/FEDORA-2026-3bacbb1eb5)/[45](https://bodhi.fedoraproject.org/updates/FEDORA-2026-f03a317854) still in testing) | ⚠️ 11 h 03 m |
| [winget](https://github.com/microsoft/winget-pkgs/pull/460528) | ⚠️ 20 h 54 m |
| Debian, Ubuntu, Alpine, Arch | ❌ no Ruby 4 at all |

## What stands out

- **The fastest ones are really fast, and mostly come from Ruby itself.** The Snap package and the `rubylang/ruby` image are both published by the Ruby core team, and were available after 7 and 8 minutes. A bot committed the ruby-build definition 28 seconds after the tarball was uploaded, and the ruby-build release followed at 43 minutes.
- **The official Docker community image took almost 16 hours.**[7](#fn:official) The Dockerfile Rails generates uses this image, so it’s also what you get with Kamal and Fly.io by default.[8](#fn:pulls) The Dockerfile itself was updated about seven hours after the tarball appeared. Most of the wait came after that, in the [official-images](https://github.com/docker-library/official-images) review and build pipeline. That review serves a purpose, but it also adds hours to the wait for a security patch.
- **Some platforms are even slower.** AWS Lambda and Elastic Beanstalk are still on 4.0.7, ~~DigitalOcean’s docs list 4.0.1–4.0.2,~~ and Google Cloud took about three and a half days to publish a 4.0.9 image, while its default for Ruby 4.0 is still 4.0.7. If you rely on a provider’s Ruby runtime, you depend on its update schedule. *Edit: Elastic Beanstalk and Lambda got 4.0.9 after 4 days. Rectification: DigitalOcean actually supports 4.0.9, as it uses Heroku buildpacks.*

## How to patch faster

Your version manager, CI and production environment all need to support the new version before you can roll it out. The slowest one decides how fast you can patch.

Some things you can do before the next Ruby security release:

- **Check the whole path to production.** Find out how your local version manager, CI and production environment pick up new Ruby releases. Look for a manual approval, a scheduled build or another step that could hold up an update.
- **Automate the boring part.** Let a bot pick up new versions of your dependencies (Ruby, your gems and your base image), run CI and deploy when everything is green. The fewer manual steps, the faster you’re patched.
- **Choose a hosting setup that lets you patch promptly.** I’d avoid relying on a provider’s Ruby runtime if it’s still two patch versions behind. Use a custom container where supported, so you can update Ruby on your own schedule.

## Most of this is volunteer work

All of this puts extra pressure on the maintainers of these tools, and most of them are volunteers. Every patch release means a chain of PRs, reviews, builds and releases across dozens of projects. The expectations keep going up.

The fastest ones show how much of that work bots can take over, so maintainers don’t have to drop everything for every release.

So a big thank you to everyone who makes this happen, often within minutes. 🙏

## Updates

- **28 October 2026:** Added [rails/devcontainer](https://github.com/rails/devcontainer) to the container images (about 9.5 hours).
- **28 October 2026:** AWS Lambda’s `ruby:4.0` image was updated to 4.0.9, about 4.5 days after the release.
- **28 October 2026:** AWS Elastic Beanstalk updated its Ruby 4.0 platform to 4.0.9 on 27 October, about 4 days after the release.
- **28 October 2026:** ruby-install’s version metadata was updated to 4.0.9, about 5.5 days after the release.
- **28 October 2026 (rectification):** DigitalOcean App Platform uses Heroku’s Ruby buildpack and binaries, so it got 4.0.9 at the same time as Heroku, even though its docs only list 4.0.1–4.0.2. Thanks to [@dblockdotorg](https://x.com/dblockdotorg/status/2115468311160897920) for confirming.

1. Amazon’s honeypots saw [the first attempts four days before disclosure](https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/). [↩](#fnref:php2shell)
2. Availability was checked through October 28. Most timestamps are Git commit dates or GitHub release dates. For Docker images I used Docker Hub’s last pushed date, or the GitHub Container Registry’s creation date for rails/devcontainer; for Heroku, the S3 `Last-Modified` header. For Homebrew it’s the bottle commit. For Google Cloud I used the upload time of the `ruby:4.0.9` runtime image in Artifact Registry. For AWS Lambda I used the creation date of the `public.ecr.aws/lambda/ruby:4.0.2026.10.27.20` image, the first one where `ruby -v` reports 4.0.9. For AWS Elastic Beanstalk I used the `DateCreated` of the Ruby 4.0 platform version 4.15.0. [↩](#fnref:times)
3. The [v4.0.9 tag](https://github.com/ruby/ruby/commit/3e93b23afcec3433f6aecc34b5d832799d754238) was pushed at 02:36 UTC, 1 h 28 m before the tarball appeared on cache.ruby-lang.org. The announcement post followed 34 minutes after the tarball. The fixes themselves were public even earlier as regular commits in the Ruby repository, and some were already part of 4.0.8. I use the tarball upload to measure how quickly downstream tools packaged the release. [↩](#fnref:tag)
4. ruby-install gets its version list and checksums from [postmodern/ruby-versions](https://github.com/postmodern/ruby-versions). This row tracks that metadata. ruby-install also [supports explicit versions, custom source URLs and checksums](https://github.com/postmodern/ruby-install#readme), so you can supply the release tarball URL and its official checksum before the metadata is updated. [↩](#fnref:ruby-install)
5. chruby switches between installed Rubies and doesn’t require an update for each release. Its documentation covers [manual installation and using either ruby-install or ruby-build](https://github.com/postmodern/chruby#rubies). With ruby-build, the release was available after 43 minutes; you could also compile the tarball yourself. [↩](#fnref:chruby)
6. DigitalOcean’s [docs](https://docs.digitalocean.com/products/app-platform/reference/buildpacks/ruby/) and [release notes](https://docs.digitalocean.com/release-notes/app-platform/) still only list Ruby 4.0.1–4.0.2. Its pinned Heroku buildpack downloads Ruby binaries from Heroku’s S3 bucket, where 4.0.9 appeared after 2 h 28 m, and [@dblockdotorg confirmed](https://x.com/dblockdotorg/status/2115468311160897920) that 4.0.9 deploys. [↩](#fnref:digitalocean)
7. What counts as ‘official’ is a bit confusing here. `ruby` is a Docker Official Image maintained by the Docker community, while `rubylang/ruby` is published by the Ruby core team itself. [↩](#fnref:official)
8. Docker Hub shows ~1.59 billion pulls for `ruby` and ~3.5 million for `rubylang/ruby`. The image that took 15 h 57 m has about 450 times as many pulls as the one available after 8 minutes. [↩](#fnref:pulls)

---

*Originally published at [Paagman.dev](https://paagman.dev/how-fast-can-you-patch-ruby/).*