Rocky Linux ou AlmaLinux pour un VPS : lequel choisir ?

Rocky Linux ou AlmaLinux : la réponse courte

Pour presque tous les serveurs, choisir entre Rocky Linux et AlmaLinux ne présente pas de mauvais choix. Les deux projets reconstruisent le même code source que Red Hat Enterprise Linux (RHEL). Ils fournissent donc les mêmes paquets avec le même cycle de support de dix ans. Les différences existent, mais elles concernent la gouvernance et un petit nombre de cas particuliers, pas l’administration quotidienne d’un serveur.

Deux éléments permettent de trancher lorsque le choix n’est pas évident. AlmaLinux 10 fournit encore une build pour les processeurs antérieurs à Intel Haswell, contrairement à Rocky Linux 10. Cela peut être important sur du matériel de VPS (virtual private server) moins cher ou plus ancien. AlmaLinux garantit également la compatibilité ABI plutôt qu’un comportement identique. Cela compte si vous exécutez un produit éditeur avec une matrice de support stricte.

D’où viennent les deux distributions

Le 8 décembre 2020, le projet CentOS a annoncé que CentOS Linux 8, une recompilation de RHEL 8, arriverait en fin de vie à la fin de 2021. Sa date de fin de vie avait été annoncée pour 2029. L’avenir du projet serait CentOS Stream. La même annonce le décrivait comme une distribution qui suit de peu une version actuelle de RHEL et comme la branche de développement en amont de RHEL. CentOS Linux 7 a conservé son calendrier initial et est arrivé en fin de vie le 30 juin 2024.

Le problème n’était pas CentOS Stream en lui-même. Le problème était qu’un cycle de vie prévu jusqu’en 2029 a été avancé de huit ans, avec un préavis d’environ un an, sur des machines déjà installées. Rocky Linux et AlmaLinux existent à cause de cette décision. Les deux distributions sont apparues en 2021 et visaient le même objectif : fournir une recompilation gratuite de RHEL qu’un administrateur pouvait installer, puis laisser en place pendant dix ans.

Ce que Rocky Linux et AlmaLinux ont en commun

Commencez par cette partie, car elle constitue l’essentiel. Les deux distributions sont reconstruites à partir des mêmes sources RHEL en amont. Elles fournissent donc les mêmes versions de paquets, le même dnf gestionnaire de paquets, la même politique SELinux (Security-Enhanced Linux), la même interface firewalld et la même organisation des unités systemd. Les fichiers de configuration se trouvent dans les mêmes chemins. Un guide écrit pour l’une fonctionne sur l’autre en remplaçant le nom de la distribution.

Les deux distributions suivent de près les versions mineures de RHEL. AlmaLinux 10.2 est sortie le 26 May 2026 et Rocky Linux 10.2 le 28 May 2026. La série 9 a évolué pendant la même semaine : AlmaLinux 9.8 le 26 May 2026 et Rocky Linux 9.8 le 27 May 2026. L’écart était plus important auparavant. AlmaLinux 10.0 est sortie le 27 May 2025 et Rocky Linux 10.0 le 11 June 2025.

Cet écart concerne les supports d’installation des versions mineures, pas la sécurité. Les deux projets publient continuellement des errata entre les versions mineures, chacun depuis son propre service d’errata. Un écart de deux semaines dans la publication d’une image .2 ne signifie pas deux semaines sans correctifs.

Les deux distributions suivent également le cycle de vie de dix ans hérité de RHEL : environ cinq ans de support actif, puis cinq ans de maintenance limitée aux correctifs de sécurité. La série 10 des deux distributions est prise en charge jusqu’en 2035.

Qui est derrière chaque projet ?

Rocky Linux relève de la Rocky Enterprise Software Foundation (RESF), une public benefit corporation du Delaware créée par Gregory Kurtzer, l’un des cofondateurs de CentOS. En novembre 2022, la RESF a ratifié des statuts et une charte qui ont transféré le contrôle des mains de son fondateur vers cette structure écrite. CIQ, une entreprise également fondée par Kurtzer, est le sponsor fondateur et vend un support commercial pour Rocky Linux.

AlmaLinux relève de l’AlmaLinux OS Foundation, une organisation à but non lucratif 501(c)(6) constituée dans le Delaware et fondée en mars 2021. Son conseil d’administration est élu par les membres de la fondation pour des mandats échelonnés de quatre ans. Les procès-verbaux des réunions sont publiés sous quatorze jours. Un article des statuts interdit à un même employeur de détenir plus d’un siège avec droit de vote au conseil, quel que soit le montant de son sponsoring. CloudLinux a lancé le projet et a renouvelé un sponsoring platinum en octobre 2024, d’un montant d’un million de dollars par an. Sa division TuxCare vend le support commercial.

Les deux structures ont été conçues pour qu’aucune entreprise ne puisse reproduire ce qui est arrivé à CentOS Linux 8. Aucune n’est manifestement plus sûre que l’autre. Ce que vous pouvez réellement vérifier est identique dans les deux cas : vous pouvez consulter les statuts et identifier l’organisation qui finance le projet.

Ce qui a changé en 2023, et est-ce toujours important ?

Le 21 juin 2023, Red Hat a annoncé que CentOS Stream deviendrait le seul dépôt public des sources des releases liées à RHEL. Avant cela, les sources des paquets RHEL étaient publiées sur git.centos.org, où les projets de rebuild les récupéraient. La suppression de ce flux n’a pas arrêté les rebuilds. Elle a obligé chaque projet à expliquer publiquement comment il obtiendrait les sources.

Rocky a répondu le 29 juin 2023. Le projet obtient les sources de RHEL à partir des images de conteneurs Universal Base Image (UBI) et d’instances de cloud public à la consommation, en partant du principe que « personne ne peut empêcher la redistribution de logiciels sous licence GPL ». En août 2023, CIQ, Oracle et SUSE ont créé l’Open Enterprise Linux Association (OpenELA), qui publie les sources nécessaires à un rebuild d’Enterprise Linux compatible bug pour bug. AlmaLinux n’en est pas membre.

AlmaLinux a répondu le 13 juillet 2023, mais sa réponse consistait à changer d’objectif. Le projet a abandonné la compatibilité bug pour bug 1:1 et adopté la compatibilité ABI. Pour reprendre ses propres termes, « nous ne serons plus tenus de garantir une compatibilité bug pour bug avec Red Hat, ce qui signifie que nous pouvons désormais accepter des corrections de bugs en dehors du cycle de release de Red Hat ». Le même billet indiquait aux utilisateurs qu’ils devaient s’attendre à « très peu de changements » au quotidien.

Trois ans plus tard, la question des sources est réglée en pratique. Les deux projets ont publié depuis chaque release mineure de RHEL, selon des calendriers similaires. Ce qui subsiste de cette controverse, c’est la différence entre les garanties de chacun.

Compatibilité bug pour bug ou compatibilité ABI : quelle différence ?

La page d’accueil de Rocky Linux décrit toujours la distribution comme conçue pour être compatible à 100 % bug pour bug avec RHEL. La compatibilité bug pour bug signifie que le rebuild reproduit le comportement de RHEL, y compris ses défauts. Si un paquet de RHEL contient un bug, le même paquet dans Rocky Linux le contient également. Un contournement décrit dans un article de la base de connaissances Red Hat s’applique donc sans adaptation.

La compatibilité ABI est plus limitée et plus précise. L’ABI, ou interface binaire d’application, est le contrat binaire dont dépend un programme compilé : noms des symboles, disposition des structures, conventions d’appel et versions des bibliothèques. Si ce contrat reste stable, un binaire compilé pour RHEL se charge et s’exécute. Cette promesse ne signifie pas que les bugs de RHEL seront également reproduits.

La conséquence est simple. AlmaLinux peut corriger un bug avant Red Hat et conserver un pilote que Red Hat a supprimé. Ces deux choix éloignent volontairement son comportement de celui de RHEL. Rocky Linux ne fera ni l’un ni l’autre, conformément à sa conception. Son comportement reste donc prévisible, exactement de la manière attendue par une certification.

La question est donc de savoir quelle promesse vous est nécessaire. Le serveur doit-il se comporter exactement comme RHEL, ou les logiciels conçus pour RHEL doivent-ils pouvoir s’y exécuter ? Dans presque tous les cas, c’est la seconde garantie qui est nécessaire.

Les paquets du fournisseur conçus pour RHEL s’installent-ils sur les deux distributions ?

Oui. Un RPM conçu pour RHEL 9 ou RHEL 10 s’installe et s’exécute sur les deux distributions, car l’ABI correspond et parce que les deux distributions se présentent aux outils comme des systèmes de la famille Red Hat. Le fichier qui fournit ces informations est /etc/os-release.

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

La copie de Rocky Linux a la même structure avec NAME="Rocky Linux" et ID="rocky", et elle indique également rhel dans ID_LIKE. Un script d’installation qui lit ID_LIKE, trouve rhel et utilise le chemin Red Hat fonctionne sur les deux distributions. Un script qui compare uniquement ID à une liste codée en dur contenant rhel, centos et fedora échoue sur les deux distributions, de manière identique, avec un message indiquant que la distribution n’est pas prise en charge. Le problème vient du script, pas d’une différence entre les deux systèmes.

La véritable exception est commerciale, et non technique. Une matrice de support est un document commercial. Le paquet d’un fournisseur peut parfaitement s’installer et fonctionner sur une distribution qui n’est pas mentionnée dans la matrice, tout en permettant au fournisseur de refuser de vous aider en cas de problème. Si vous payez ce support, consultez la matrice et laissez-la guider votre choix. C’est le seul cas où la décision est prise à votre place.

Lequel fonctionne encore sur les anciens processeurs ?

RHEL 10 a relevé le niveau de microarchitecture x86-64 de référence à x86-64-v3. Ce niveau correspond à la génération Haswell d’Intel et à Excavator d’AMD, et nécessite des extensions du jeu d’instructions telles qu’AVX2. Rocky Linux 10 suit RHEL sur ce point. Sa documentation indique que x86-64-v3 est le niveau de référence et que le niveau v2 et les niveaux antérieurs ne sont plus pris en charge.

AlmaLinux 10 fournit par défaut la build v3 et ajoute une build distincte x86-64-v2. Selon ses propres termes, cette build permet aux utilisateurs disposant de matériel plus ancien de continuer à recevoir des mises à jour de sécurité pendant encore dix ans. AlmaLinux recompile également les paquets EPEL pour cette architecture, car les paquets RHEL 10 tiers ciblent v3. C’est le point important à connaître avant de compter dessus : la build v2 convient à l’ensemble de paquets par défaut ainsi qu’à l’EPEL v2 d’AlmaLinux, mais vous devez recompiler vous-même tout le reste pour v2.

Cela compte davantage sur un VPS que sur du matériel dont vous êtes propriétaire, car vous ne choisissez pas le processeur de l’hôte. Sur les hôtes anciens ou moins chers, ou lorsque l’hyperviseur présente au guest un modèle de processeur conservateur, la machine virtuelle peut ne pas exposer AVX2, même si la puce physique le prend en charge. Les paquets compilés pour v3 tentent alors d’utiliser des instructions absentes du processeur et échouent. Vérifiez ce que votre instance expose réellement avant de déployer toute une flotte sur la série 10. La série 9 des deux distributions fonctionne encore au niveau v2. Sur les instances ARM plutôt que sur les instances x86, la question ne se pose jamais, car les niveaux de microarchitecture sont un concept propre à x86-64.

La même liberté apparaît ailleurs dans AlmaLinux 10. Le projet a réactivé la prise en charge de plus de 150 périphériques supprimés par l’upstream, notamment les identifiants PCI d’anciens contrôleurs RAID et iSCSI, et a réactivé SPICE pour les usages serveur et client. Les frame pointers sont activés par défaut, ce qui permet le profiling à l’échelle du système. Une promesse de compatibilité bug pour bug interdit toutes ces modifications ; c’est donc la décision prise en 2023 qui a permis cette marge de manœuvre.

Comment migrer un serveur CentOS ou RHEL existant ?

Rocky Linux publie des scripts de conversion dans son dépôt rocky-tools. migrate2rocky.sh convertit un système Enterprise Linux 8 en Rocky Linux 8, et migrate2rocky9.sh effectue la même opération pour la série 9. Chaque script fonctionne au sein d’une seule version majeure. En août 2026, le dépôt ne contient aucun script équivalent pour Enterprise Linux 10. Passer à Rocky Linux 10 nécessite donc une réinstallation.

AlmaLinux publie almalinux-deploy.sh. Cet outil prend en charge Enterprise Linux 8, 9 et 10 et permet de convertir CentOS Stream, Oracle Linux, RHEL, Rocky Linux, MiracleLinux et Virtuozzo Linux sur x86_64, aarch64, ppc64le et s390x. Lisez ses limites documentées avant de commencer. Seul le boot loader GRUB2 est pris en charge sur les systèmes qui en ont besoin. De plus, un kernel personnalisé comme l’UEK (unbreakable enterprise kernel) d’Oracle n’est pas supprimé automatiquement. La machine ne peut alors plus démarrer avec Secure Boot.

Pour passer d’une version majeure à une autre, AlmaLinux maintient ELevate, basé sur le framework leapp de Red Hat. Les chemins documentés sont CentOS 7 vers EL8, AlmaLinux 8 ou CentOS Stream 8 vers EL9, et AlmaLinux 9 ou CentOS Stream 9 vers EL10. La documentation indique la cible sous la forme EL8, EL9 ou EL10 au lieu de nommer une distribution. Vous choisissez en effet l’Enterprise Linux sur lequel vous voulez aboutir.

Toutes ces méthodes réécrivent les release packages et réinstallent une grande partie du système. Créez d’abord un snapshot chez votre fournisseur. Exécutez la conversion dans screen ou tmux, comme le recommande la documentation d’AlmaLinux. Une connexion SSH interrompue en cours d’opération peut laisser la machine dans un état que vous ne voudrez pas devoir diagnostiquer depuis une rescue console.

Alors, lequel choisir ?

Pour une charge de travail VPS classique, les deux conviennent. Ils installent les mêmes paquets et arrivent en fin de support la même année. Choisissez-en un, utilisez-le sur tous les serveurs que vous administrez et n’y pensez plus. La cohérence compte davantage que leurs différences, car un parc mixte double le nombre d’images et de flux d’errata à suivre. Ce coût augmente rapidement dès que vous administrez plusieurs serveurs Linux à la fois.

Les exceptions sont limitées et chacune dépend d’un élément extérieur à votre préférence.

• Le processeur de votre hôte est antérieur à Haswell, ou l’hyperviseur masque AVX2 au guest. AlmaLinux 10 propose un build x86-64-v2. Rocky Linux 10 n’en propose pas.
• Un fournisseur auquel vous faites appel cite une distribution précise dans sa matrice de support. Utilisez celle-ci.
• Vous avez besoin d’un comportement identique à RHEL pour une certification ou un audit. Rocky Linux indique viser une compatibilité bug pour bug, tandis que l’objectif d’AlmaLinux est explicitement différent.
• Vous convertissez un serveur en fonctionnement au lieu d’en créer un nouveau. Les outils d’AlmaLinux prennent actuellement en charge davantage de distributions sources et de versions majeures, notamment Enterprise Linux 10.

Si la vraie question porte sur Enterprise Linux ou une autre distribution, c’est le modèle de cycle de vie que vous choisissez. Une distribution Enterprise Linux vous offre dix ans avec le même jeu de paquets, sans changement de version à planifier. Les versions Ubuntu avec support à long terme vous offrent cinq ans de support standard, avec un chemin de mise à niveau pris en charge tous les deux ans. C’est un compromis différent, décrit dans la comparaison entre les versions Ubuntu LTS et les versions intermédiaires. Quelle que soit la distribution installée, la première heure sur la machine se déroule de la même manière. Suivez donc les dix premières minutes sur un nouveau VPS avant d’y installer quoi que ce soit.

FAQ

Rocky Linux ou AlmaLinux est-il le plus proche de Red Hat Enterprise Linux ?

Rocky Linux, selon son objectif déclaré. Sa page d’accueil décrit la distribution comme conçue pour être compatible avec RHEL à 100 %, bug pour bug. Cela signifie qu’elle vise à reproduire le comportement de RHEL, y compris ses défauts. AlmaLinux a annoncé le 13 juillet 2023 qu’il viserait plutôt la compatibilité ABI (application binary interface). Les logiciels conçus pour RHEL peuvent donc y fonctionner, même si le code sous-jacent contient des correctifs que RHEL n’a pas encore publiés. Pour exécuter des logiciels serveur courants, les deux distributions sont équivalentes. Pour une certification qui exige le comportement de RHEL, cette distinction est essentielle.

Puis-je passer de Rocky Linux à AlmaLinux sans réinstaller le système ?

Oui, dans ce sens. Le almalinux-deploy.sh d’AlmaLinux liste Rocky Linux 8, 9 et 10 parmi ses sources prises en charge, avec CentOS Stream, Oracle Linux, RHEL et MiracleLinux. Le changement dans l’autre sens est plus limité : le dépôt rocky-tools de Rocky fournit des scripts de conversion pour Enterprise Linux 8 et 9 uniquement. Il n’existe donc pas de méthode de conversion sur place vers Rocky Linux 10 en août 2026. Créez un snapshot avant toute conversion et exécutez-la depuis une session qui résiste à une perte de connexion, car le processus remplace les release packages et réinstalle une grande partie du système.

Les packages conçus pour RHEL fonctionnent-ils sur les deux distributions ?

Oui, pour les packages RPM courants et les dépôts tiers. Les deux distributions conservent l’interface binaire applicative de RHEL et s’identifient avec ID_LIKE="rhel centos fedora" dans /etc/os-release. Un package ou un script d’installation qui vérifie la présence d’un système de la famille Red Hat suit donc le chemin approprié. L’exception est d’ordre commercial, et non technique : un éditeur peut prendre en charge uniquement les distributions mentionnées dans sa matrice de support, même si son package s’installe et fonctionne sur les deux. Si vous payez ce support, fiez-vous à la matrice.

Quelle distribution choisir sur un VPS peu coûteux doté d’un processeur ancien ?

AlmaLinux, si vous voulez utiliser la série 10. RHEL 10 a relevé la configuration minimale x86-64 au niveau de la microarchitecture v3. Cela nécessite un processeur du niveau d’Intel Haswell ou d’AMD Excavator, et Rocky Linux 10 suit cette configuration minimale. AlmaLinux 10 fournit en plus un build x86-64-v2 pour le matériel ancien, avec dix ans de mises à jour de sécurité. Vérifiez ce que votre instance expose avant de vous décider, car une machine virtuelle voit le modèle de processeur que lui fournit l’hyperviseur, et pas toujours l’ensemble des instructions du serveur hôte. La série 9 des deux distributions fonctionne encore sur du matériel v2.