How fast can you actually patch Ruby?

When I tried to update an app to Ruby 4.0.9 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 eight hours after the patch went out. Last week, PHP2Shell was being exploited before it was announced.1 Waiting for a Docker image can eat up the time you have to respond.

I took every installer and version manager listed on the official installation page on ruby-lang.org, then added container images, CI providers and hosting platforms I could think of. For each, I checked when 4.0.9 became available.2

All times start when the Ruby 4.0.9 source tarball became available, on Friday 23 October 2026, 04:04 UTC.3

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:

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. 🙏

Amazon’s honeypots saw the first attempts four days before disclosure. ↩

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. ↩

The v4.0.9 tag 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. ↩

ruby-install gets its version list and checksums from postmodern/ruby-versions. This row tracks that metadata. ruby-install also supports explicit versions, custom source URLs and checksums, so you can supply the release tarball URL and its official checksum before the metadata is updated. ↩

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. With ruby-build, the release was available after 43 minutes; you could also compile the tarball yourself. ↩

DigitalOcean’s docs and release notes 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 that 4.0.9 deploys. ↩

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. ↩

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. ↩

I've got some availability for new clients! If you're looking for someone with 15 years of Rails experience and a deep feel for Hotwire, who's all in on building with AI agents, let's chat.