Rocky Linux vs AlmaLinux: which for a VPS?

Rocky Linux vs AlmaLinux: the short answer

For almost every server, Rocky Linux vs AlmaLinux is a choice with no wrong answer. Both projects rebuild the same Red Hat Enterprise Linux (RHEL) source code, so they ship the same packages on the same ten year support lifecycle. The differences are real, but they live in governance and in a small number of edge cases, not in the daily work of running a box.

Two things decide it when it is not a coin flip. AlmaLinux 10 still ships a build for processors older than Intel Haswell and Rocky Linux 10 does not, which matters on cheaper or older VPS (virtual private server) hardware. AlmaLinux also promises ABI compatibility rather than identical behaviour, which matters if you run a vendor product with a strict support matrix.

Where both distributions came from

On 8 December 2020 the CentOS project announced that CentOS Linux 8, a rebuild of RHEL 8, would end at the end of 2021. It had been published with an end date in 2029. The project's future was CentOS Stream, which the same announcement described as tracking just ahead of a current RHEL release and serving as the upstream development branch of RHEL. CentOS Linux 7 kept its original schedule and reached end of life on 30 June 2024.

The problem was not CentOS Stream itself. The problem was that a lifecycle ending in 2029 moved by eight years with about a year of notice, on machines that were already installed. Rocky Linux and AlmaLinux both exist because of that. Both appeared in 2021 and both aimed at the same job: a free rebuild of RHEL that an operator could install and then leave alone for a decade.

What Rocky Linux and AlmaLinux share

Start here, because the shared part is most of the picture. Both rebuild from the same upstream RHEL sources, so both give you the same package versions, the same dnf package manager, the same SELinux (security enhanced Linux) policy, the same firewalld front end and the same systemd unit layout. Configuration files sit in the same paths. A guide written for one works on the other with the name changed.

Both track RHEL minor releases closely. AlmaLinux 10.2 shipped on 26 May 2026 and Rocky Linux 10.2 on 28 May 2026. The 9 series moved in the same week: AlmaLinux 9.8 on 26 May 2026 and Rocky Linux 9.8 on 27 May 2026. Earlier the gap was wider. AlmaLinux 10.0 arrived on 27 May 2025 and Rocky Linux 10.0 on 11 June 2025.

That gap is about minor release media, not about security. Both projects publish errata continuously between minor releases, each from its own errata service. A two week difference in when a .2 image appears does not mean two weeks without patches.

Both also carry the ten year lifecycle model they inherited from RHEL: roughly five years of active support, then five years of security only maintenance. The 10 series on both runs into 2035.

Who stands behind each project?

Rocky Linux belongs to the Rocky Enterprise Software Foundation (RESF), a Delaware public benefit corporation created by Gregory Kurtzer, a co-founder of CentOS. In November 2022 the RESF ratified bylaws and a charter that moved control out of its founder's hands and into that written structure. CIQ, a company Kurtzer also founded, is the founding sponsor and sells commercial support for Rocky Linux.

AlmaLinux belongs to the AlmaLinux OS Foundation, a 501(c)(6) non profit incorporated in Delaware and founded in March 2021. Its board is elected by the foundation's members on staggered four year terms, meeting minutes are published within fourteen days, and a bylaw prevents any single employer from holding more than one voting board seat regardless of how much it sponsors. CloudLinux started the project and renewed a platinum sponsorship in October 2024 worth one million dollars a year. Its TuxCare division sells the commercial support.

Both structures were built so that no single company can repeat what happened to CentOS Linux 8, and neither is obviously safer than the other. What you can actually check is the same in both cases: you can read the bylaws, and you can name the organisation writing the cheques.

What changed in 2023, and does it still matter?

On 21 June 2023 Red Hat announced that CentOS Stream would become the sole repository for public RHEL related source code releases. Before that, RHEL package sources appeared on git.centos.org, which is where the rebuilds took them from. Removing that feed did not stop the rebuilds. It did force each project to answer, in public, how it would get sources.

Rocky answered on 29 June 2023. It obtains RHEL sources from Universal Base Image (UBI) container images and from pay per use public cloud instances, on the reasoning that "no one can prevent redistribution of GPL software". In August 2023 CIQ, Oracle and SUSE created the Open Enterprise Linux Association (OpenELA), which publishes the sources needed for a bug for bug compatible Enterprise Linux rebuild. AlmaLinux is not a member.

AlmaLinux answered on 13 July 2023, and its answer was a change of goal. The project dropped 1:1 bug for bug compatibility and adopted ABI compatibility instead. In its own words, "we will no longer be held to the line of bug-for-bug compatibility with Red Hat, and that means that we can now accept bug fixes outside of Red Hat's release cycle". The same post told users to expect "very little change" in daily use.

Three years on, the sourcing question is settled in practice. Both projects have shipped every RHEL minor release since, on similar schedules. What survived the argument is the difference in what each one promises.

Bug for bug or ABI compatible: what is the difference?

Rocky Linux's homepage still describes the distribution as designed to be 100% bug for bug compatible with RHEL. Bug for bug means the rebuild reproduces RHEL's behaviour including its defects. If a package in RHEL carries a bug, the same package in Rocky Linux carries it too, so a workaround from a Red Hat knowledge base article applies without translation.

ABI compatibility is narrower and more precise. The ABI, or application binary interface, is the binary contract a compiled program depends on: symbol names, structure layouts, calling conventions and library versions. Keep that contract stable and a binary built against RHEL loads and runs. The promise says nothing about matching RHEL's bugs.

The consequence is easy to state. AlmaLinux can fix a bug before Red Hat does, and it can keep a driver that Red Hat removed. Both of those move its behaviour away from RHEL on purpose. Rocky Linux will not do either, by design, so it stays predictable in exactly the way a certification cares about.

So the question is which promise you need. Do you need the server to behave identically to RHEL, or do you need software built for RHEL to run on it? Almost everyone needs the second one.

Will vendor packages built for RHEL install on both?

Yes. An RPM built for RHEL 9 or RHEL 10 installs and runs on both, because the ABI matches and because both distributions present themselves to tooling the way a Red Hat family system does. The file that does the presenting is /etc/os-release.

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

Rocky Linux's copy has the same shape with NAME="Rocky Linux" and ID="rocky", and it lists rhel in ID_LIKE as well. An installer script that reads ID_LIKE, finds rhel and takes the Red Hat path works on both. A script that only compares ID against a hard coded list of rhel, centos and fedora fails on both, and it fails identically on each, with an unsupported distribution message. That is a bug in the script, not a difference between the two systems.

The real exception is commercial rather than technical. A support matrix is a business document. A vendor's package can install and run perfectly on a distribution the matrix does not name, and the vendor can still decline to help you when it breaks. If you pay for that support, read the matrix and let it choose for you. This is the one case where the decision is made for you.

Which one still runs on older CPUs?

RHEL 10 raised the baseline x86-64 microarchitecture level to x86-64-v3. That level matches Intel's Haswell generation and AMD's Excavator, and it requires instruction set extensions such as AVX2. Rocky Linux 10 follows RHEL here. Its documentation states that x86-64-v3 is the baseline and that the v2 level and earlier are no longer supported.

AlmaLinux 10 ships the v3 build as the default and adds a separate x86-64-v2 build, in its own words to let users on that older hardware keep receiving security updates for another ten years. AlmaLinux also rebuilds EPEL packages for that architecture, because third party RHEL 10 packages target v3. That is the catch worth knowing before you rely on it: the v2 build suits the default package set plus AlmaLinux's own v2 EPEL, and anything else has to be rebuilt for v2 by you.

This matters more on a VPS than on hardware you own, because you do not choose the host processor. On older or cheaper hosts, or where the hypervisor presents a conservative CPU model to the guest, the virtual machine may not expose AVX2 even when the physical chip has it. Packages built for v3 then reach for instructions the processor does not have, so they fail. Check what your instance actually exposes before you commit a fleet to the 10 series. The 9 series of both distributions still runs at the v2 level. On ARM instances rather than x86 instances the question never comes up, because microarchitecture levels are an x86-64 concept.

The same freedom shows up elsewhere in AlmaLinux 10. The project re-enabled support for more than 150 devices that upstream removed, including PCI IDs for older RAID and iSCSI controllers, and it re-enabled SPICE for both server and client use. Frame pointers are on by default, which is what makes system wide profiling work. A bug for bug promise forbids every one of those changes, so the 2023 decision is what bought the room to make them.

How do you migrate an existing CentOS or RHEL server?

Rocky Linux publishes conversion scripts in its rocky-tools repository. migrate2rocky.sh converts an Enterprise Linux 8 system to Rocky Linux 8, and migrate2rocky9.sh does the same for the 9 series. Each works within a single major version. As of August 2026 the repository holds no equivalent script for Enterprise Linux 10, so moving to Rocky Linux 10 means a reinstall.

AlmaLinux publishes almalinux-deploy.sh, which covers Enterprise Linux 8, 9 and 10 and converts from CentOS Stream, Oracle Linux, RHEL, Rocky Linux, MiracleLinux and Virtuozzo Linux, across x86_64, aarch64, ppc64le and s390x. Its documented limits are worth reading before you start. Only the GRUB2 boot loader is supported on systems that need one, and a custom kernel such as Oracle's UEK (unbreakable enterprise kernel) is not removed automatically, which leaves the machine unable to boot under Secure Boot.

For a jump between major versions, AlmaLinux maintains ELevate, built on Red Hat's leapp framework. The documented paths are CentOS 7 to EL8, AlmaLinux 8 or CentOS Stream 8 to EL9, and AlmaLinux 9 or CentOS Stream 9 to EL10. The documentation writes the target as EL8, EL9 or EL10 rather than naming one distribution, because you choose which Enterprise Linux you land on.

Any of these rewrites the release packages and reinstalls a large part of the system. Take a provider snapshot first. Run the conversion inside screen or tmux, as AlmaLinux's own documentation advises, because a dropped SSH connection halfway through leaves a machine in a state you do not want to debug from a rescue console.

So which one should you pick?

For a typical VPS workload, either. They install the same packages and they reach end of support in the same year. Pick one, use it on every server you run, and stop thinking about it. Consistency is worth more than the difference between them, because a mixed fleet doubles the number of images and errata feeds you track. That cost grows fast once you are managing several Linux servers at once.

The exceptions are narrow, and every one of them is decided by something outside your preference.

• Your host processor is older than Haswell, or the hypervisor hides AVX2 from the guest. AlmaLinux 10 has an x86-64-v2 build. Rocky Linux 10 does not.
• A vendor you pay names one distribution in its support matrix. Use that one.
• You need behaviour identical to RHEL for a certification or an audit. Rocky Linux's stated goal is bug for bug compatibility, and AlmaLinux's goal explicitly is not.
• You are converting a running server instead of building a fresh one. AlmaLinux's tooling currently covers more source distributions and more major versions, including Enterprise Linux 10.

If the real question is Enterprise Linux against something else, then the lifecycle model is what you are choosing. An Enterprise Linux distribution gives you ten years on one package set with no version jumps to plan. Ubuntu's long term support releases give you five years of standard support with a supported upgrade path every two years, which is a different bargain and is worked through in the comparison of Ubuntu LTS and interim releases. Whichever you install, the first hour on the machine looks the same, so work through the first ten minutes on a new VPS before you put anything on it.

FAQ

Is Rocky Linux or AlmaLinux closer to Red Hat Enterprise Linux?

Rocky Linux, by its own stated goal. Its homepage describes the distribution as designed to be 100% bug for bug compatible with RHEL, which means it aims to reproduce RHEL's behaviour including its defects. AlmaLinux announced on 13 July 2023 that it would target ABI (application binary interface) compatibility instead, so software built for RHEL runs on it while the code underneath may carry fixes RHEL has not shipped. For running normal server software the two are equivalent. For a certification that names RHEL behaviour, the distinction is the whole point.

Can I switch from Rocky Linux to AlmaLinux without reinstalling?

Yes, in that direction. AlmaLinux's almalinux-deploy.sh lists Rocky Linux 8, 9 and 10 among its supported sources, along with CentOS Stream, Oracle Linux, RHEL and MiracleLinux. Going the other way is more limited: Rocky's rocky-tools repository ships conversion scripts for Enterprise Linux 8 and 9 only, so there is no in-place path to Rocky Linux 10 as of August 2026. Take a snapshot before any conversion and run it from a session that survives a dropped connection, because the process replaces the release packages and reinstalls much of the system.

Do packages built for RHEL work on both?

Yes, for ordinary RPM packages and third party repositories. Both distributions keep the RHEL application binary interface, and both identify themselves with ID_LIKE="rhel centos fedora" in /etc/os-release, so a package or installer script that checks for a Red Hat family system takes the right path. The exception is commercial rather than technical: a vendor may support only the distributions its support matrix names, even though its package installs and runs on both. If you pay for that support, let the matrix decide.

Which should I use on a low cost VPS with an older CPU?

AlmaLinux, if you want the 10 series. RHEL 10 raised the x86-64 baseline to the v3 microarchitecture level, which needs a processor at Intel Haswell or AMD Excavator level, and Rocky Linux 10 follows that baseline. AlmaLinux 10 ships an additional x86-64-v2 build for older hardware, with ten years of security updates behind it. Check what your instance exposes before committing, because a virtual machine sees the CPU model the hypervisor gives it and not always the host's full instruction set. The 9 series of both distributions still runs on v2 hardware.