How fast can you actually patch Ruby?

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

Installers and version managers

Container images

CI

Hosting platforms

System packages

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 The Dockerfile Rails generates uses this image, so it’s also what you get with Kamal and Fly.io by default.8 The Dockerfile itself was updated about seven hours after the tarball appeared. Most of the wait came after that, in the 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 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 for confirming.

1. Amazon’s honeypots saw the first attempts four days before disclosure. ↩
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. ↩
3. 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. ↩
4. 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. ↩
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. With ruby-build, the release was available after 43 minutes; you could also compile the tarball yourself. ↩
6. 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. ↩
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. ↩
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. ↩

---

Originally published at Paagman.dev.