Zusammenfassung

  • Docker Hubs Betriebsdokumente nennen 100 Pulls in sechs Stunden ohne Anmeldung und 200 für angemeldete Personal-Nutzer. Die Preis-FAQ nennt dagegen 10 beziehungsweise 100 pro Stunde.
  • Das offizielle Update vom 8. April 2025 erklärt, die für den 1. April vorgesehene Änderung sei nicht umgesetzt worden. Auf derselben Anbieterwebsite bleiben verschiedene Mengen und Zeitfenster sichtbar.

Ein Kapazitätsplan kann fehlerfrei rechnen und trotzdem die falsche Uhr benutzen. Bei Docker Hub steht die eine in der Betriebsdokumentation, die andere in der Preis-FAQ. Beide gehören demselben Anbieter. Der Kunde darf sich aussuchen, an welcher Stelle er mit dem Nachlesen beginnt, aber nicht, welches Zeitfenster seine Arbeit tatsächlich begrenzt.

Die Betriebsdokumente nennen für unangemeldete Nutzung 100 Pulls je IPv4-Adresse oder IPv6-/64-Subnetz innerhalb von sechs Stunden. Angemeldete Personal-Nutzer erhalten dort 200 in sechs Stunden. Die Preis-FAQ nennt 10 pro Stunde und IP ohne Anmeldung sowie 100 pro Stunde und Nutzer für angemeldetes Personal. Menge und Zeitraum verändern sich gemeinsam.

Die Korrektur hat ein Datum

Docker veröffentlichte den Beitrag zur Überarbeitung seiner Hub-Richtlinien am 21. Februar 2025. Ein Update vom 8. April erklärt, die für den 1. April geplanten Änderungen der Rate Limits seien nicht durchgesetzt worden. Die Kontingente von 100 und 200 pro sechs Stunden blieben bestehen. Die heutigen Betriebsdokumente passen zu dieser datierten Aussage.

Die Preis-FAQ führt weiter Stundenwerte und verweist gleichzeitig auf Dokumentation und Richtlinien-Updates. Einkaufseinstieg und Betriebsbeschreibung geben damit unterschiedliche Ausgangspunkte. Wer den Stand des Anbieters verstehen will, muss den Weg durch die Links selbst zu Ende gehen.

Veröffentlichung Ohne Anmeldung Personal mit Anmeldung
Betriebsdokumentation 100 je IPv4 oder IPv6 /64 in sechs Stunden 200 in sechs Stunden
Preis-FAQ 10 je IP und Stunde 100 je Nutzer und Stunde
Update vom 8. April 2025 100 in sechs Stunden beibehalten 200 in sechs Stunden beibehalten

Eine aktuelle Limitantwort oder ein entsprechender Header auf dem tatsächlichen Build-Pfad des Käufers würde das diesem Client zugewiesene Kontingent belegen und könnte seine Kapazitätsplanung verändern.

Die veröffentlichte Differenz reicht bereits für eine Einkaufsfrage. Das Kontingent fließt in die Entscheidung ein, wann Aufgaben starten, welche warten und weshalb ein bezahlter Plan sinnvoll wird. Eine Zahl nahe am Kaufknopf findet schnell den Weg in eine Tabelle. Dort kann sie eine saubere Rechnung mit einer verschobenen Voraussetzung erzeugen.

Der Durchschnitt startet keinen Build

Den Stundenwert mit sechs zu multiplizieren macht aus zwei Fenstern noch keine gemeinsame Betriebsregel. Entscheidend ist, wann Arbeit ankommt. Eine gebündelte Nachfrage und ein längeres Summenfenster wirken anders als einzelne Stundenlimits. Ein freundlicher Durchschnitt verspricht keinen freien Startplatz für die nächste Welle.

Der wirtschaftliche Gegenstand ist ein Build, der in den Lieferplan passt. Pull-Zahl, Zuordnung und Anfragerhythmus tragen dazu bei. Wird nur die größte Zahl kopiert, fehlt die Zeitangabe, die aus ihr nutzbare Kapazität macht.

Die Auflösung des Widerspruchs verbraucht Arbeit: Dokumente prüfen, Annahmen ändern, Aufgaben neu verteilen, den Kauf noch einmal bewerten. Docker hat die Korrektur bereits datiert. Jeder Kunde, der sie erneut mit der Preis-FAQ verbinden muss, übernimmt ein Stück liegen gebliebener Websitepflege.

Bezahlt ist ein abgegrenztes Angebot

Die Betriebsdokumente nennen unbegrenzte gewöhnliche Pull-Raten für angemeldetes Pro, Team und Business unter Fair-Use-Bedingungen. Daneben besteht ein separater Missbrauchsschutz, der nach IPv4-Adresse oder IPv6 /64 für alle Kontostufen gilt. Seine Schwelle verändert sich mit Last und weiteren Faktoren.

Der Kaufgrund muss deshalb die beabsichtigte Entlastung benennen. Normales Pull-Kontingent, Identitätszuordnung und netzseitiger Herkunftsschutz beantworten verschiedene Fragen. Nach der falschen Uhr auf einen höheren Plan zu wechseln kann eine andere Grenze verändern, ohne die ursprüngliche Wartezeit erklärt zu haben.

Docker kontrolliert Angebote, Veröffentlichungen und Ausführungsregeln. Der Käufer kontrolliert Kauf und autorisierte Identität. Eine externe Plattform kann den gemeinsamen Netzausgang kontrollieren. Die Build-Teams verbinden diese Teile, um Arbeit auszuliefern. Eine widersprüchliche Einheit am Kaufweg fügt genau dort Koordination hinzu, wo das Produkt sie einsparen soll.

Die geschäftliche Reparatur ist überschaubar: Menge, Zeitraum und Anwendungsstand auf den Einkaufsseiten zusammenführen. Eine bereits veröffentlichte Korrektur muss auch den Leser erreichen, der zuerst den anderen Wert sieht. Ein neues Dashboard zur Übersetzung einer alten FAQ wäre eine sehr aufwendige Form des Nichtaufräumens.

Entwicklerwerkzeuge verdienen ihren Platz durch weniger Abstimmungsarbeit. Das Zeitfenster um ihr Kontingent gehört zu diesem Geschäft. Docker kann Regeln ändern. Die Entscheidung bis zum Einstieg des Käufers weiterzureichen gehört ebenfalls zur Lieferung.

Quellen