Acht Minuten lagen im Oktober 2026 zwischen dem Ruby-4.0.9-Tarball und dem aktualisierten Container-Image rubylang/ruby. Das ist der schnellste Wert in einer Messung, die zeigt, wie unterschiedlich Ruby-Patches bis in die Produktion gelangen. Bei Patch-Geschwindigkeit denkt man meist an den Release selbst. Die Zahlen von Paagman.dev verschieben den Blick: Entscheidend ist nicht nur, wann das Ruby-Team eine Sicherheitslücke schließt, sondern wann dein Version Manager, dein CI-System, dein Container-Image und deine Hosting-Plattform dieselbe Version ausliefern. Der Autor hat für Ruby 4.0.9 Installer, Version Manager, Container Images, CI-Anbieter und Hosting-Plattformen systematisch geprüft. Das ist wie bei einer Logistikkette: Das Ersatzteil ist ab Werk verfügbar, muss aber noch durch mehrere Lager, Prüfstellen und Werkstätten, bis es im Fahrzeug sitzt. Die langsamste Station bestimmt den Termin. Erst dort entscheidet sich, wie schnell ein Patch wirklich bei dir ankommt.
Sieben Minuten bis fast fünf Tage: die Ruby-Patch-Geschwindigkeit im Überblick
Die Messung beginnt am Freitag, 23. Oktober 2026, um 04:04 UTC, als der Quellcode-Tarball von Ruby 4.0.9 auf cache.ruby-lang.org erschien. Ab dann verfolgte der Autor, wann die einzelnen Werkzeuge und Plattformen nachzogen. Die Spanne ist groß: Das Snap-Paket war nach sieben Minuten verfügbar, das Image rubylang/ruby nach acht Minuten. ruby-build folgte nach 43 Minuten, das offizielle Docker-Community-Image ruby erst nach 15 Stunden und 57 Minuten. AWS Lambda brauchte rund 4 Tage und 16 Stunden, die Metadaten von ruby-install sogar etwa 5 Tage und 10 Stunden. Die Zahlen kommen nicht von einem einzelnen Anbieter, sondern aus der ganzen Ruby-Infrastruktur.
Dabei werden unterschiedliche Dinge gemessen. Bei Version Managern zählt oft der Git-Commit oder das GitHub-Release, bei Docker-Images der letzte Push auf Docker Hub, bei Hosting-Plattformen das Bereitstellungsdatum der Runtime. Das ist methodisch nicht immer gleich, zeigt aber genau das, was im Alltag zählt: Wann kann eine Anwendung tatsächlich auf die neue Version wechseln. Der Bericht nennt einen Fall, in dem eine Regierungs-Rails-Anwendung acht Stunden nach dem Patch von einer ActiveStorage-Lücke getroffen wurde. Wer in dieser Zeit noch auf ein Docker-Image wartet, hat ein Problem, das nicht im Ruby-Repository liegt.
Warum das Ruby Docker Image fast 16 Stunden braucht
Beim Docker-Image lohnt der genaue Blick, weil hier leicht zwei Dinge verwechselt werden. Das Image ruby ist ein Docker Official Image, das die Docker-Community pflegt. Das Image rubylang/ruby veröffentlicht das Ruby-Core-Team selbst. Deshalb war rubylang/ruby nach acht Minuten da, während ruby fast 16 Stunden brauchte. Das von Rails erzeugte Dockerfile nutzt das Community-Image ruby. Wer mit Kamal, Fly.io oder einer ähnlichen Umgebung auf diesem Standard aufsetzt, erbt diese Wartezeit. Der Dockerfile selbst war laut Bericht etwa sieben Stunden nach dem Tarball aktualisiert; der größere Teil der Verzögerung entstand danach im Review- und Build-Prozess der Official Images.
Das soll die Qualitätssicherung nicht kritisieren. Ein Review hat einen Zweck, und ein offizielles Image soll nicht leichtfertig verändert werden. Nur hilft dieser Zweck wenig, wenn es um eine Sicherheitslücke geht. Der Bericht zeigt den Kontrast: ruby kommt auf etwa 1,59 Milliarden Pulls, rubylang/ruby auf rund 3,5 Millionen. Das viel genutztere Image war rund 450-mal häufiger im Einsatz und trotzdem fast 16 Stunden langsamer als das Image des Ruby-Teams. Für die Frage, wie schnell ein Ruby-Patch verfügbar ist, ist das ein zentraler Befund. Wie schnell das ruby docker image aktualisiert wird, hängt nicht am Ruby-Release allein, sondern an einer zusätzlichen Veröffentlichungskette.
Ruby Version Manager im Vergleich: von ruby-build bis ruby-install
Bei den Version Managern wiederholt sich dieselbe Logik in kleinerem Maßstab. Ein Bot committete die ruby-build-Definition 28 Sekunden nach dem Hochladen des Tarballs; das eigentliche ruby-build-Release folgte nach 43 Minuten. Die ruby/ruby-builder-Binaries waren nach 48 Minuten da, Homebrew ruby-build nach 1 Stunde und 10 Minuten. asdf brauchte 2 Stunden und 43 Minuten, die vorkompilierten Rubies von mise über jdx/ruby etwa 8 Stunden und 15 Minuten. RVM lag bei 18 Stunden und 34 Minuten, rv bei 21 Stunden und 40 Minuten. RubyInstaller für Windows kam nach 16 Stunden und 35 Minuten, die Metadaten von ruby-install erst nach mehr als fünf Tagen.
Ein einfacher Sieger lässt sich beim ruby version manager update vergleich also nicht küren. ruby-install kann zum Beispiel explizite Versionen, eigene Quell-URLs und Prüfsummen verarbeiten. Wer den Tarball und die offizielle Checksumme selbst mitbringt, ist nicht auf die späte Metadaten-Aktualisierung angewiesen. chruby verwaltet nur installierte Rubies und braucht gar kein Update pro Release; die Geschwindigkeit hängt davon ab, ob ruby-build oder ruby-install im Hintergrund arbeitet. rbenv für Windows war laut Bericht schon im März bei 4.0.1 stehengeblieben. Wer mise nutzt, sollte prüfen, ob die vorkompilierte Variante oder der ruby-build-Weg verwendet wird. Der Unterschied zwischen 43 Minuten und mehr als acht Stunden liegt oft in dieser Einstellung.
Ruby Sicherheitspatch auf Hosting-Plattformen: Heroku, AWS und Google Cloud
In der Produktion wird es ernst, weil dort nicht nur ein Werkzeug aktualisiert wird. Heroku hatte Ruby 4.0.9 nach 2 Stunden und 28 Minuten, DigitalOcean App Platform zum selben Zeitpunkt, weil sie Herokus Ruby-Buildpack und dessen Binaries nutzt. Die Dokumentation von DigitalOcean listete noch ältere Versionen; der Autor korrigierte diese Einschätzung nach einem Hinweis. Northflank lag ebenfalls bei 2 Stunden und 28 Minuten, Scalingo bei 2 Stunden und 29 Minuten, Hatchbox über asdf bei 2 Stunden und 43 Minuten. Railway folgte über mise nach 8 Stunden und 15 Minuten. Fly.io, Kamal und andere Umgebungen, die auf dem offiziellen Docker-Community-Image aufsetzen, erbten die fast 16 Stunden.
Noch langsamer waren einige große Cloud-Runtimes. Google Cloud brauchte etwa 3 Tage und 14 Stunden für ein Ruby-4.0.9-Image, während die Standardversion für Ruby 4.0 weiterhin 4.0.7 war. AWS Elastic Beanstalk aktualisierte seine Ruby-4.0-Plattform nach etwa 4 Tagen und 4 Stunden, AWS Lambda nach rund 4 Tagen und 16 Stunden. Render ist ein Sonderfall: Die native Runtime kann eine neue Ruby-Version kompilieren, sobald der Tarball verfügbar ist. Der Autor testete das mit 4.1.0-preview1, nicht mit 4.0.9; der Fallback über ruby-install funktionierte in etwa 1 Minute und 47 Sekunden. Wann Renders vorgebaute 4.0.9-Version erschien, ist nicht bekannt. Für die ruby hosting plattform update dauer heißt das: Eine verwaltete Runtime ist bequem, aber du übernimmst den Aktualisierungsrhythmus des Anbieters.
So verkürzt du die Ruby Update Dauer in deiner Produktionskette
Die wichtigste Konsequenz aus den Zahlen ist einfach: Die langsamste Station entscheidet, wie schnell du patchen kannst. Dein lokaler Version Manager, deine CI und deine Produktionsumgebung müssen die neue Version unterstützen, bevor der Rollout beginnt. Prüfe deshalb die ganze Strecke, nicht nur den ersten Schritt. Wo wird die Ruby-Version festgelegt? Gibt es eine manuelle Freigabe, einen geplanten Build oder einen Cache, der ein Update blockiert? Wie lange dauert es, bis ein neues Basis-Image in der Produktion ankommt? Wer diese Fragen erst stellt, wenn eine Ruby-Sicherheitslücke veröffentlicht wurde, verliert die Zeit, die er braucht.
Der zweite Hebel ist Automatisierung. Lass einen Bot neue Versionen von Ruby, deinen Gems und deinem Basis-Image erkennen, CI ausführen und bei grünen Tests deployen. Das nimmt nicht jede Entscheidung ab, entfernt aber die manuellen Schritte, die im Ernstfall niemand mehr sauber abarbeitet. Der dritte Hebel ist die Wahl des Hostings. Wenn eine Plattform bei Ruby noch zwei Patch-Versionen hinterherhängt, ist sie für sicherheitskritische Anwendungen keine gute Standardwahl. Nutze wo möglich ein eigenes Container-Image, damit du Ruby nach deinem eigenen Zeitplan aktualisieren kannst. Wie schnell ein Ruby-Patch für dich verfügbar ist, zeigt sich erst, wenn alle Stationen deiner Kette grün sind.
Meist Freiwilligenarbeit: was die Patch-Geschwindigkeit über die Ruby-Infrastruktur sagt
Hinter den Minuten und Stunden steht viel Arbeit, die leicht übersehen wird. Jedes Patch-Release erzeugt eine Kette aus Pull Requests, Reviews, Builds und Releases über Dutzende Projekte. Die meisten Maintainer machen das freiwillig. Die Erwartungen steigen trotzdem, und ein Sicherheitspatch macht keinen Urlaub. Der Bericht zeigt, wie viel ein Bot übernehmen kann: Die ruby-build-Definition war nach 28 Sekunden da. Das ist kein Zufall, sondern das Ergebnis einer Automatisierung, die Maintainer entlastet, ohne ihnen die Verantwortung abzunehmen. Diese Arbeit gehört zur Patch-Geschwindigkeit dazu.
Die Zahlen sind deshalb keine Rangliste guter und schlechter Projekte. Sie zeigen, wo Verantwortung liegt und wo Verzögerungen entstehen. Für Betreiber heißt das: Prüfe deine eigene Kette, automatisiere die langweiligen Teile und plane die langsamste Station ein. Acht Minuten sind möglich, aber nicht der Standard. Wer das weiß, kann eine Ruby-Sicherheitslücke besser einordnen und muss im Ernstfall nicht erst herausfinden, dass das eigene Docker-Image noch auf den Review wartet. Die ruby patch geschwindigkeit hängt am Ende von der ganzen Produktionskette ab, nicht nur vom Ruby-Release.
Quelle: paagman.dev
