Rocky Linux vs AlmaLinux: which should you actually run?

Every CentOS 7 exit ends at the same little fork in the road. You've decided to stay in the Red Hat family — sensible, it's the least disruptive move — and you don't want to pay for RHEL on every last box. So it's Rocky Linux or AlmaLinux. I've run both, in production, on things that mattered. Here's the honest version, minus the forum flame wars.

Same parents, different family meetings

Both were born the same week in December 2020, when Red Hat announced that CentOS Linux was becoming CentOS Stream — an upstream preview of RHEL instead of a downstream rebuild of it. Overnight, the free, rock-stable, bug-for-bug RHEL clone that half the internet ran in prod had an expiry date. Two projects stood up to fill the hole.

Rocky Linux was started by Gregory Kurtzer — who co-founded the original CentOS, so there's a bit of poetry to it — backed by his company CIQ and governed by the Rocky Enterprise Software Foundation. AlmaLinux was started by CloudLinux and then handed off to a community-owned nonprofit, the AlmaLinux OS Foundation. Both shipped their first stable release in 2021. Both are free. And both are, for very nearly everything you'll ever do with them, the same operating system.

The 2023 thing you'll hear about

In mid-2023 Red Hat tightened access to RHEL source code, and this is the one place the two projects genuinely diverge in philosophy. Rocky kept chasing bug-for-bug identity with RHEL, getting at the sources through channels Red Hat's own terms permit — UBI container images, pay-as-you-go cloud instances. AlmaLinux made a different call: stop promising a 1:1 identical rebuild and instead promise ABI compatibility — binary-compatible, so anything certified for RHEL still runs, even if a given package isn't byte-for-byte the same.

In practice this almost never reaches down and touches you. But if your compliance story leans hard on the words "bit-for-bit RHEL," Rocky's framing is closer to that; if you value a foundation-owned governance model with no single company holding the keys, Alma's is. Reasonable people picked different sides and both are still here, years later, shipping updates on time.

What's actually different, day to day

Honestly? Almost nothing. Same package versions, same kernel, same SELinux, same dnf, same roughly ten-year support lifecycle. I've shuffled workloads between the two and the practical diff is the string in /etc/os-release and the mirror URLs. Alma every so often ships a security fix a touch differently because of how it sources; Rocky every so often lands one a day earlier or later. Stretched over years, it's noise.

So how do you actually pick?

• Check your vendor's support matrix first. If an ISV certifies your database or your app server, some list Rocky and Alma by name and some still only say RHEL. That list will settle the argument faster then any philosophical debate about governance.
• If you want paid support, both have it — CIQ behind Rocky, CloudLinux and TuxCare behind Alma. Get quotes from both; it's a normal conversation.
• If governance is your thing, Alma's nonprofit-foundation structure appeals to people who got burned by the CentOS pivot and want daylight between the distro and any one vendor. Rocky's sits closer to CIQ.
• Otherwise, flip a coin. I'm not being glib — for a standard EL9 workload either one is a perfectly good ten-year home, and there governance model is far more likely to matter to your procurement team than to your uptime.

The part that matters more than the pick

Here's the thing nobody mentions at this fork: which rebuild you land on matters a lot less than whether you can prove the workload survived the move. Rocky and Alma are both EL9. That's two major versions up from the CentOS 7 you're leaving — a real jump, not a sidestep. Packages got renamed, split, and shuffled around between EL7 and EL9, defaults changed, some things that were separate got merged.

If your standardizing a whole fleet, the risk was never "I chose the wrong rebuild." It's "half these boxes came out subtly different from the originals and I have no clean way to tell which ones." That's the failure that shows up in an incident review, not a distro benchmark.

Which is the problem vrtmv is built for. It reads the old CentOS box, translates the package and config set to whichever target you chose — Rocky or Alma, doesn't care — generates the rebuild, and signs a parity report, so "equivalent" is something you can hand an auditor instead of a feeling you have. Pick the distro on governance and vendor support. Prove the migration on evidence. Those are two different jobs and only one of them is a coin flip.

Rocky or Alma is honestly one of the lowest-stakes calls in your entire CentOS exit. Give it twenty minutes, point at whichever your vendor matrix or your gut prefers, and pour the saved energy into the migration itself — because that's where the actual risk has been hiding the whole time.