Rocky Linux vs AlmaLinux: Was ist besser für VPS?

Rocky Linux vs AlmaLinux: die kurze Antwort

Für fast jeden Server ist Rocky Linux vs AlmaLinux eine Entscheidung ohne falsche Option. Beide Projekte erstellen ihre Pakete aus demselben Quellcode von Red Hat Enterprise Linux (RHEL) neu. Daher liefern sie dieselben Pakete mit demselben zehnjährigen Support-Lebenszyklus aus. Die Unterschiede sind real. Sie betreffen jedoch die Governance und wenige Sonderfälle, nicht den täglichen Betrieb eines Servers.

Zwei Punkte sind ausschlaggebend, wenn die Entscheidung nicht per Münzwurf fällt. AlmaLinux 10 liefert weiterhin einen Build für Prozessoren aus, die älter als Intel Haswell sind. Rocky Linux 10 tut das nicht. Das ist bei günstigerer oder älterer VPS-Hardware (virtueller privater Server) relevant. AlmaLinux verspricht außerdem ABI-Kompatibilität statt identischem Verhalten. Das ist wichtig, wenn Sie ein Produkt eines Herstellers mit einer strikten Support-Matrix betreiben.

Woher beide Distributionen stammen

Am 8. Dezember 2020 kündigte das CentOS-Projekt an, dass CentOS Linux 8, ein Rebuild von RHEL 8, Ende 2021 eingestellt werde. Ursprünglich war das Ende für 2029 angekündigt worden. Die Zukunft des Projekts sollte CentOS Stream sein. In derselben Ankündigung wurde es als Entwicklungszweig beschrieben, der knapp vor einem aktuellen RHEL-Release liegt und als Upstream-Entwicklungszweig von RHEL dient. CentOS Linux 7 behielt seinen ursprünglichen Zeitplan bei und erreichte am 30. Juni 2024 das Ende seiner Lebensdauer.

Das Problem war nicht CentOS Stream selbst. Das Problem war, dass sich ein für 2029 geplantes Lebenszyklusende mit etwa einem Jahr Vorankündigung um acht Jahre verschob. Das betraf Systeme, die bereits installiert waren. Rocky Linux und AlmaLinux gibt es aus genau diesem Grund. Beide entstanden 2021 und hatten dasselbe Ziel: ein kostenloser Rebuild von RHEL, den ein Administrator installieren und anschließend ein Jahrzehnt unverändert betreiben konnte. Warum CentOS diese Rolle ursprünglich übernahm und wie aus einer Red-Hat-Linux-Distribution Fedora, RHEL und eine Reihe von Rebuilds wurden, wird in der ausführlicheren Geschichte hinter Red Hat, CentOS, Rocky und AlmaLinux beschrieben.

Was Rocky Linux und AlmaLinux gemeinsam haben

Beginnen Sie hier, denn der gemeinsame Teil macht den größten Teil des Gesamtbilds aus. Beide Distributionen werden aus denselben Upstream-Quellen von RHEL neu gebaut. Daher bieten beide dieselben Paketversionen, denselben dnf-Paketmanager, dieselbe SELinux-(security enhanced Linux-)Richtlinie, dasselbe firewalld-Frontend und dasselbe systemd-Unit-Layout. Die Konfigurationsdateien befinden sich in denselben Pfaden. Eine Anleitung für die eine Distribution funktioniert auch auf der anderen, wenn Sie den Namen austauschen. Das gilt auch für praktische Aufgaben: Docker Engine installieren läuft auf beiden gleich ab, bis hin zum podman-Paket, das den docker-Befehl bereitstellt, und zur SELinux-Neukennzeichnung, die Bind-Mounts benötigen. Auch die Firewall verhält sich gleich. Daher verwendet SSH und einen Webport mit firewalld öffnen auf beiden Distributionen identische firewall-cmd-Befehle, einschließlich des --permanent-Flags, das festlegt, ob eine Regel einen Reboot übersteht.

Beide Distributionen folgen den Minor-Releases von RHEL eng. AlmaLinux 10.2 wurde am 26. Mai 2026 veröffentlicht, Rocky Linux 10.2 am 28. Mai 2026. Die Serie 9 wurde in derselben Woche aktualisiert: AlmaLinux 9.8 am 26. Mai 2026 und Rocky Linux 9.8 am 27. Mai 2026. Zuvor war der Abstand größer. AlmaLinux 10.0 erschien am 27. Mai 2025, Rocky Linux 10.0 am 11. Juni 2025.

Dieser Abstand betrifft die Medien für Minor-Releases, nicht die Sicherheit. Beide Projekte veröffentlichen zwischen den Minor-Releases fortlaufend Errata, jeweils über ihren eigenen Errata-Dienst. Ein Unterschied von zwei Wochen beim Erscheinen eines .2-Images bedeutet nicht, dass zwei Wochen lang keine Patches verfügbar sind. Diese Errata ohne Anmeldung abzurufen, funktioniert auf beiden Distributionen gleich. Daher umfasst dnf-automatic für die zeitgesteuerte Installation von Sicherheitsupdates konfigurieren auf beiden Systemen dieselben Schritte, unabhängig davon, welche Distribution Sie installiert haben. Einen Patch zu installieren ist nicht dasselbe wie ihn auszuführen. ermitteln, für welche Updates ein Reboot und für welche ein Dienstneustart erforderlich ist verwendet auf beiden Systemen denselben needs-restarting-Befehl, weil beide ihn aus demselben RHEL-Paket übernehmen.

Beide Distributionen übernehmen außerdem das von RHEL geerbte Lebenszyklusmodell mit zehn Jahren: ungefähr fünf Jahre aktiver Support, anschließend fünf Jahre reine Sicherheitswartung. Die Serie 10 läuft bei beiden bis 2035.

Wer steht hinter den einzelnen Projekten?

Rocky Linux gehört der Rocky Enterprise Software Foundation (RESF), einer in Delaware gegründeten Public-Benefit-Corporation. Gegründet wurde sie von Gregory Kurtzer, einem Mitgründer von CentOS. Im November 2022 verabschiedete die RESF eine Satzung und eine Gründungsurkunde. Damit wurde die Kontrolle aus den Händen des Gründers in diese schriftlich festgelegte Struktur überführt. CIQ, ein ebenfalls von Kurtzer gegründetes Unternehmen, ist der Gründungssponsor und verkauft kommerziellen Support für Rocky Linux.

AlmaLinux gehört der AlmaLinux OS Foundation, einer in Delaware eingetragenen gemeinnützigen Organisation nach 501(c)(6), die im März 2021 gegründet wurde. Der Vorstand wird von den Mitgliedern der Foundation für gestaffelte Amtszeiten von vier Jahren gewählt. Sitzungsprotokolle werden innerhalb von vierzehn Tagen veröffentlicht. Eine Satzungsregel verhindert außerdem, dass ein einzelner Arbeitgeber mehr als einen stimmberechtigten Vorstandssitz hält, unabhängig von der Höhe seines Sponsorings. CloudLinux startete das Projekt und verlängerte im Oktober 2024 ein Platinum-Sponsoring im Wert von einer Million Dollar pro Jahr. Die Abteilung TuxCare verkauft den kommerziellen Support.

Beide Strukturen wurden so geschaffen, dass kein einzelnes Unternehmen die Ereignisse rund um CentOS Linux 8 wiederholen kann. Keine der beiden Strukturen ist offensichtlich sicherer als die andere. Was Sie tatsächlich in beiden Fällen prüfen können, ist identisch: Sie können die Satzungen lesen und feststellen, welche Organisation die Zahlungen leistet.

Was hat sich 2023 geändert, und ist das noch relevant?

Am 21. Juni 2023 kündigte Red Hat an, dass CentOS Stream das einzige Repository für öffentlich veröffentlichte RHEL-bezogene Quellcodes werden sollte. Zuvor waren die RHEL-Paketquellen auf git.centos.org verfügbar. Von dort bezogen die Rebuilds ihre Quellen. Durch das Entfernen dieses Feeds wurden die Rebuilds nicht beendet. Jedes Projekt musste jedoch öffentlich darlegen, wie es künftig an die Quellen gelangen würde.

Rocky antwortete am 29. Juni 2023. Das Projekt bezieht RHEL-Quellen aus Universal Base Image (UBI)-Container-Images und aus öffentlichen Cloud-Instanzen mit nutzungsabhängiger Abrechnung. Die Begründung lautet: „Niemand kann die Weiterverteilung von GPL-Software verhindern.“ Im August 2023 gründeten CIQ, Oracle und SUSE die Open Enterprise Linux Association (OpenELA). Sie veröffentlicht die Quellen, die für einen fehlergenau kompatiblen Enterprise-Linux-Rebuild benötigt werden. AlmaLinux ist kein Mitglied.

AlmaLinux antwortete am 13. Juli 2023. Die Antwort bestand in einer Änderung des Ziels. Das Projekt gab die 1:1-Fehlerkompatibilität auf und übernahm stattdessen ABI-Kompatibilität. In den eigenen Worten des Projekts: „Wir sind künftig nicht mehr an die Fehler-für-Fehler-Kompatibilität mit Red Hat gebunden. Dadurch können wir jetzt auch Fehlerkorrekturen außerhalb des Release-Zyklus von Red Hat übernehmen.“ Im selben Beitrag wurden die Benutzer darauf hingewiesen, dass sie im täglichen Einsatz „sehr wenige Änderungen“ erwarten sollten.

Drei Jahre später ist die Frage der Quellenbeschaffung in der Praxis geklärt. Beide Projekte haben seitdem jedes RHEL-Minor-Release veröffentlicht, und zwar nach ähnlichen Zeitplänen. Von der Auseinandersetzung ist der Unterschied darin geblieben, was die beiden Projekte jeweils zusichern.

Fehleridentisch oder ABI-kompatibel: Was ist der Unterschied?

Auf der Homepage von Rocky Linux wird die Distribution weiterhin als dafür entwickelt beschrieben, zu 100 % fehleridentisch mit RHEL kompatibel zu sein. Fehleridentisch bedeutet, dass der Rebuild das Verhalten von RHEL einschließlich seiner Fehler reproduziert. Wenn ein Paket in RHEL einen Fehler enthält, enthält dasselbe Paket in Rocky Linux diesen ebenfalls. Eine Lösung aus einem Red-Hat-Knowledge-Base-Artikel kann daher ohne Anpassung angewendet werden.

Die ABI-Kompatibilität ist enger gefasst und präziser. Die ABI, also die Application Binary Interface, ist der binäre Vertrag, von dem ein kompiliertes Programm abhängt: Symbolnamen, Layouts von Strukturen, Aufrufkonventionen und Bibliotheksversionen. Dieser Vertrag bleibt stabil, sodass ein für RHEL erstelltes Binary geladen und ausgeführt wird. Die Zusage bedeutet nicht, dass die Fehler von RHEL ebenfalls übernommen werden.

Die Folge lässt sich einfach zusammenfassen. AlmaLinux kann einen Fehler beheben, bevor Red Hat dies tut. Außerdem kann AlmaLinux einen Treiber beibehalten, den Red Hat entfernt hat. Beides entfernt das Verhalten absichtlich vom Verhalten von RHEL. Rocky Linux tut beides konstruktionsbedingt nicht und bleibt daher genau auf die Weise vorhersehbar, die für eine Zertifizierung relevant ist.

Entscheidend ist daher, welche Zusage Sie benötigen. Muss sich der Server identisch wie RHEL verhalten, oder müssen darauf für RHEL erstellte Programme ausgeführt werden? Fast alle benötigen die zweite Variante.

Installieren sich für RHEL erstellte Anbieterpakete auf beiden Systemen?

Ja. Ein für RHEL 9 oder RHEL 10 erstelltes RPM lässt sich auf beiden Systemen installieren und ausführen, weil die ABI übereinstimmt und beide Distributionen sich gegenüber Tools als Red-Hat-Systeme aus der entsprechenden Familie ausgeben. Die Datei, die diese Angaben bereitstellt, ist /etc/os-release.

NAME="AlmaLinux"
ID="almalinux"
ID_LIKE="rhel centos fedora"

Die Kopie von Rocky Linux hat mit NAME="Rocky Linux" und ID="rocky" dieselbe Struktur. Außerdem führt sie rhel in ID_LIKE auf. Ein Installationsskript, das ID_LIKE liest, rhel findet und den Red-Hat-Pfad verwendet, funktioniert auf beiden Systemen. Ein Skript, das ID nur mit einer fest codierten Liste aus rhel, centos und fedora vergleicht, schlägt auf beiden Systemen fehl. Auf jedem System erscheint dabei dieselbe Meldung über eine nicht unterstützte Distribution. Das ist ein Fehler im Skript und kein Unterschied zwischen den beiden Systemen.

Die tatsächliche Ausnahme ist geschäftlicher und nicht technischer Natur. Eine Support-Matrix ist ein Geschäftsdokument. Das Paket eines Anbieters kann sich auf einer Distribution problemlos installieren und ausführen lassen, die in der Matrix nicht aufgeführt ist. Trotzdem kann der Anbieter die Unterstützung verweigern, wenn ein Fehler auftritt. Wenn Sie für diesen Support bezahlen, lesen Sie die Matrix und richten Sie Ihre Entscheidung danach. Dies ist der einzige Fall, in dem Ihnen die Entscheidung abgenommen wird.

Welche Distribution läuft noch auf älteren CPUs?

RHEL 10 hat die minimale x86-64-Mikroarchitekturstufe auf x86-64-v3 angehoben. Diese Stufe entspricht der Haswell-Generation von Intel und Excavator von AMD und erfordert Befehlssatzerweiterungen wie AVX2. Rocky Linux 10 folgt RHEL in diesem Punkt. In der Dokumentation wird x86-64-v3 als Mindeststufe angegeben; die Stufe v2 und ältere Stufen werden nicht mehr unterstützt.

AlmaLinux 10 liefert standardmäßig den v3-Build aus und stellt zusätzlich einen separaten x86-64-v2-Build bereit. Nach eigener Aussage soll dies Nutzern älterer Hardware ermöglichen, weitere zehn Jahre lang Sicherheitsupdates zu erhalten. AlmaLinux erstellt auch EPEL-Pakete für diese Architektur neu, weil Pakete von Drittanbietern für RHEL 10 auf v3 abzielen. Das ist der wichtige Punkt: Der v2-Build eignet sich für den Standardsatz an Paketen sowie für das eigene v2-EPEL von AlmaLinux. Alles Weitere müssen Sie selbst für v2 neu erstellen.

Bei einem VPS ist das wichtiger als bei eigener Hardware, weil Sie den Host-Prozessor nicht auswählen. Auf älteren oder günstigeren Hosts oder wenn der Hypervisor der virtuellen Maschine ein konservatives CPU-Modell präsentiert, stellt die VM möglicherweise kein AVX2 bereit, selbst wenn der physische Chip dies unterstützt. Für v3 erstellte Pakete greifen dann auf Befehle zu, die der Prozessor nicht unterstützt, und schlagen fehl. Prüfen Sie, welche Funktionen Ihre Instanz tatsächlich bereitstellt, bevor Sie eine ganze Flotte auf die 10er-Serie umstellen. Die 9er-Serie beider Distributionen läuft weiterhin auf der Stufe v2. Bei ARM-Instanzen statt x86-Instanzen stellt sich diese Frage nicht, weil Mikroarchitekturstufen ein Konzept von x86-64 sind.

Dieselbe größere Flexibilität zeigt sich auch an anderer Stelle in AlmaLinux 10. Das Projekt hat die Unterstützung für mehr als 150 Geräte wieder aktiviert, die der Upstream entfernt hatte. Dazu gehören PCI-IDs älterer RAID- und iSCSI-Controller. Außerdem wurde SPICE für die Verwendung auf Servern und Clients wieder aktiviert. Frame Pointer sind standardmäßig aktiviert. Dadurch funktioniert das systemweite Profiling. Eine Bug-for-Bug-Zusage verbietet all diese Änderungen. Die Entscheidung aus dem Jahr 2023 hat daher den nötigen Spielraum dafür geschaffen.

Wie migrieren Sie einen vorhandenen CentOS- oder RHEL-Server?

Rocky Linux veröffentlicht Konvertierungsskripte in seinem Repository rocky-tools. migrate2rocky.sh konvertiert ein Enterprise-Linux-8-System zu Rocky Linux 8, migrate2rocky9.sh übernimmt dasselbe für die 9er-Serie. Beide Skripte funktionieren innerhalb einer einzelnen Hauptversion. Im August 2026 enthält das Repository kein entsprechendes Skript für Enterprise Linux 10. Der Wechsel zu Rocky Linux 10 erfordert daher eine Neuinstallation.

AlmaLinux veröffentlicht almalinux-deploy.sh. Dieses Skript unterstützt Enterprise Linux 8, 9 und 10 und konvertiert Systeme von CentOS Stream, Oracle Linux, RHEL, Rocky Linux, MiracleLinux und Virtuozzo Linux auf x86_64, aarch64, ppc64le und s390x. Lesen Sie die dokumentierten Einschränkungen, bevor Sie beginnen. Auf Systemen, die einen Bootloader benötigen, wird ausschließlich GRUB2 unterstützt. Ein benutzerdefinierter Kernel wie Oracles UEK (Unbreakable Enterprise Kernel) wird nicht automatisch entfernt. Dadurch kann das System unter Secure Boot nicht mehr starten.

Für einen Wechsel zwischen Hauptversionen pflegt AlmaLinux ELevate, das auf dem leapp-Framework von Red Hat basiert. Die dokumentierten Upgrade-Pfade sind CentOS 7 zu EL8, AlmaLinux 8 oder CentOS Stream 8 zu EL9 sowie AlmaLinux 9 oder CentOS Stream 9 zu EL10. Die Dokumentation verwendet als Ziel EL8, EL9 oder EL10, statt eine bestimmte Distribution zu nennen. Sie wählen selbst, auf welcher Enterprise-Linux-Distribution das System anschließend läuft.

Jedes dieser Verfahren ersetzt die Release-Pakete und installiert einen großen Teil des Systems neu. Erstellen Sie zuerst einen Snapshot beim Provider. Führen Sie die Konvertierung innerhalb von screen oder tmux aus, wie es die AlmaLinux-Dokumentation empfiehlt. Wird die SSH-Verbindung während des Vorgangs unterbrochen, bleibt der Rechner andernfalls möglicherweise in einem Zustand zurück, den Sie nicht über eine Rettungskonsole untersuchen möchten.

Welche Distribution sollten Sie also wählen?

Für eine typische VPS-Workload sind beide geeignet. Sie installieren dieselben Pakete und erreichen im selben Jahr das Ende des Supports. Wählen Sie eine davon, verwenden Sie sie auf jedem von Ihnen betriebenen Server und machen Sie sich darüber keine weiteren Gedanken. Einheitlichkeit ist wichtiger als der Unterschied zwischen den beiden, weil eine gemischte Flotte die Anzahl der zu überwachenden Images und Errata-Feeds verdoppelt. Dieser Aufwand steigt schnell, sobald Sie mehrere Linux-Server gleichzeitig verwalten.

Die Ausnahmen sind begrenzt. Jede davon wird durch einen Faktor außerhalb Ihrer persönlichen Präferenz bestimmt.

• Ihr Host-Prozessor ist älter als Haswell, oder der Hypervisor blendet AVX2 für den Gast aus. AlmaLinux 10 verfügt über einen x86-64-v2-Build. Rocky Linux 10 nicht.
• Ein Anbieter, den Sie bezahlen, nennt eine der beiden Distributionen in seiner Support-Matrix. Verwenden Sie diese.
• Sie benötigen für eine Zertifizierung oder ein Audit ein Verhalten, das mit RHEL identisch ist. Das erklärte Ziel von Rocky Linux ist Bug-für-Bug-Kompatibilität. Das erklärte Ziel von AlmaLinux ist dies ausdrücklich nicht.
• Sie konvertieren einen laufenden Server, statt einen neuen aufzusetzen. Die Werkzeuge von AlmaLinux unterstützen derzeit mehr Quelldistributionen und mehr Hauptversionen, darunter Enterprise Linux 10.

Wenn es bei der eigentlichen Frage um Enterprise Linux im Vergleich zu einer anderen Distribution geht, wählen Sie das Lifecycle-Modell. Eine Enterprise-Linux-Distribution bietet Ihnen zehn Jahre lang dieselbe Paketbasis, ohne dass Sie Versionssprünge planen müssen. Die Long-Term-Support-Releases von Ubuntu bieten fünf Jahre Standardsupport mit einem unterstützten Upgrade-Pfad alle zwei Jahre. Das ist ein anderes Modell und wird in dem Vergleich von Ubuntu-LTS- und Interim-Releases erläutert. Unabhängig davon, was Sie installieren, sieht die erste Stunde auf dem System gleich aus. Arbeiten Sie daher zunächst die ersten zehn Minuten auf einem neuen VPS durch, bevor Sie etwas darauf einrichten.

FAQ

Ist Rocky Linux oder AlmaLinux näher an Red Hat Enterprise Linux?

Rocky Linux, entsprechend dem eigenen erklärten Ziel. Auf der Homepage wird die Distribution als zu 100 % „bug for bug“ mit RHEL kompatibel beschrieben. Das bedeutet, dass sie das Verhalten von RHEL einschließlich dessen Fehlern nachbilden soll. AlmaLinux kündigte am 13. Juli 2023 an, stattdessen ABI-Kompatibilität (Application Binary Interface) anzustreben. Für RHEL entwickelte Software läuft dadurch auf AlmaLinux, während der zugrunde liegende Code bereits Fehlerkorrekturen enthalten kann, die RHEL noch nicht veröffentlicht hat. Für den Betrieb normaler Serversoftware sind beide Distributionen gleichwertig. Bei einer Zertifizierung, die ausdrücklich das Verhalten von RHEL voraussetzt, ist dieser Unterschied entscheidend.

Kann ich ohne Neuinstallation von Rocky Linux zu AlmaLinux wechseln?

Ja, in diese Richtung. Die almalinux-deploy.sh von AlmaLinux führt Rocky Linux 8, 9 und 10 als unterstützte Ausgangssysteme auf, außerdem CentOS Stream, Oracle Linux, RHEL und MiracleLinux. Der umgekehrte Weg ist eingeschränkter: Das rocky-tools von Rocky Linux enthält Konvertierungsskripte nur für Enterprise Linux 8 und 9. Daher gibt es mit Stand August 2026 keinen In-Place-Weg zu Rocky Linux 10. Erstellen Sie vor jeder Konvertierung einen Snapshot. Führen Sie sie außerdem aus einer Sitzung aus, die eine unterbrochene Verbindung übersteht, weil der Vorgang die Release-Pakete ersetzt und große Teile des Systems neu installiert.

Funktionieren für RHEL erstellte Pakete auf beiden Distributionen?

Ja, bei gewöhnlichen RPM-Paketen und Repositories von Drittanbietern. Beide Distributionen behalten die RHEL-Application-Binary-Interface bei. Außerdem weisen sich beide in /etc/os-release mit ID_LIKE="rhel centos fedora" aus. Ein Paket oder Installationsskript, das ein System aus der Red-Hat-Familie prüft, wählt daher den richtigen Pfad. Die Ausnahme ist eher vertraglicher als technischer Natur: Ein Anbieter unterstützt möglicherweise nur die Distributionen, die in seiner Support-Matrix aufgeführt sind, auch wenn sich sein Paket auf beiden installieren und ausführen lässt. Wenn Sie für diesen Support bezahlen, ist die Matrix maßgeblich.

Welche Distribution sollte ich auf einem kostengünstigen VPS mit einer älteren CPU verwenden?

AlmaLinux, wenn Sie die Serie 10 verwenden möchten. RHEL 10 hat die x86-64-Baseline auf die v3-Mikroarchitekturstufe angehoben. Dafür ist mindestens ein Prozessor auf dem Niveau von Intel Haswell oder AMD Excavator erforderlich. Rocky Linux 10 folgt dieser Baseline. AlmaLinux 10 stellt zusätzlich einen x86-64-v2-Build für ältere Hardware bereit, für den zehn Jahre lang Sicherheitsupdates angeboten werden. Prüfen Sie vor der Entscheidung, welche CPU-Merkmale Ihre Instanz bereitstellt. Eine virtuelle Maschine sieht das CPU-Modell, das ihr der Hypervisor zuweist, und nicht immer den vollständigen Befehlssatz des Hosts. Die Serie 9 beider Distributionen läuft weiterhin auf v2-Hardware.