Rocky Linux and AlmaLinux Release History: Versions and Support Dates

AlmaLinux and Rocky Linux exist because Red Hat and the CentOS Project announced in December 2020 that CentOS Linux 8 would end on 31 December 2021, eight years early. AlmaLinux shipped its first stable release, 8.3, on 30 March 2021, and Rocky Linux reached general availability with 8.4 on 21 June 2021. Both now follow the same ten year clock: version 8 is supported until 31 May 2029, version 9 until 31 May 2032 and version 10 until 31 May 2035.

As of this writing (24 October 2026), the current releases are AlmaLinux 10.2 and 9.8 (both 26 May 2026) and Rocky Linux 10.2 (29 May 2026) and 9.8 (28 May 2026). Both projects keep version 8 on its final minor release, 8.10, in security maintenance. AlmaLinux 10.3 and 9.9 are in beta. The two distributions look alike from a distance, but since June 2023 they have taken different routes to staying compatible with Red Hat Enterprise Linux (RHEL), and they publish security data in different formats. Those differences matter when you plan support windows, feed a vulnerability scanner or pick a base image.

Key takeaways

• Both projects were born from the CentOS Linux 8 cut. The CentOS Project's December 2020 post said CentOS Linux 8, "as a rebuild of RHEL 8, will end at the end of 2021". CentOS Linux 8 reached end of life on 31 December 2021 and CentOS Linux 7 on 30 June 2024.
• AlmaLinux shipped first; Rocky reached GA second. AlmaLinux 8.3 "Purple Manul" went stable on 30 March 2021 for x86_64 only. Rocky Linux's release table lists 8.3 on 1 May 2021, but its announcement of general availability came with 8.4 on 21 June 2021.
• Ten years per major version, five of them "active". Each major version gets roughly five years of minor releases every six months, ending at .10, then five years of security maintenance. Only the newest minor release of each major version is supported.
• Governance differs. The AlmaLinux OS Foundation is a US 501(c)(6) member organisation with elected leadership. Rocky Linux is a project of the Rocky Enterprise Software Foundation (RESF), led by a board chaired by CentOS founder Gregory Kurtzer.
• June 2023 split their goals. After Red Hat made CentOS Stream "the sole repository for public RHEL-related source code releases", AlmaLinux moved from bug-for-bug rebuilding to ABI compatibility, while Rocky kept a bug-for-bug goal and sourced RHEL code through UBI container images and pay-per-use cloud instances.
• Advisories map to Red Hat IDs, with different prefixes. AlmaLinux publishes ALSA, ALBA and ALEA advisories; Rocky publishes RLSA, RLBA and RLEA. Both feed dnf updateinfo. AlmaLinux adds OVAL streams and errata JSON; Rocky's Apollo errata service exposes an OSV endpoint.
• Version 10 splits on hardware. Rocky Linux 10 requires x86-64-v3 processors and adds riscv64. AlmaLinux 10 ships both x86-64-v3 and x86_64_v2 builds, so older hardware stays in scope.
• Verify before you trust. AlmaLinux signs its ISO CHECKSUM file with the release key. Rocky publishes key fingerprints you can compare with gpg --show-keys. Check a fingerprint against the project's own page, not against a mirror.

This post goes one level deeper than our Fedora, CentOS Stream and RHEL pipeline post, which explains where RHEL code comes from. Here we follow it downstream. For scanning a Rocky Linux container specifically, see scanning a Rocky Linux container image. For other distributions' release histories, see Debian release history and Alpine Linux release history.

Why AlmaLinux and Rocky Linux exist

The December 2020 CentOS Stream announcement

Until 2020, CentOS Linux was the free, community rebuild of RHEL. Red Hat published the source RPMs for each RHEL update to git.centos.org, and the CentOS Project rebuilt them with Red Hat trademarks removed. Millions of servers, container base images and hosting panels relied on the result being as close to RHEL as possible, with the same bugs and the same fixes, at no cost.

On 8 December 2020 the CentOS Project published CentOS Project shifts focus to CentOS Stream. It said the project was moving its focus "from CentOS Linux, the rebuild of Red Hat Enterprise Linux (RHEL), to CentOS Stream, which tracks just ahead of a current RHEL release". The key sentence for operators was that CentOS Linux 8 would end "at the end of 2021", while CentOS Linux 7 would continue for the rest of the RHEL 7 life cycle. CentOS Stream continued as "the upstream (development) branch" of RHEL.

The change mattered because many teams had assumed CentOS Linux 8 would follow RHEL 8's ten year life cycle, which Red Hat's own life cycle data puts at 31 May 2029 for the end of maintenance support. The 718 comments under the post show how many teams had just finished moving from CentOS 6 and 7 to 8. CentOS Stream is a different product: it is where changes for the next RHEL minor release land first, so it runs slightly ahead of RHEL rather than matching a released RHEL point version. For a team that wanted a free, frozen, RHEL-equivalent server, Stream was not a drop-in replacement.

The CentOS Linux end dates

The CentOS Project's CentOS Linux EOL page set the dates: "CentOS Linux 8 will reach End of Life on December 31, 2021." It also said the project would not automatically migrate anyone to CentOS Stream 8. In 2023 a follow-up post, End dates are coming for CentOS Stream 8 and CentOS Linux 7, confirmed two more dates: CentOS Stream 8 "End of Builds" on 31 May 2024, roughly matching RHEL 8.10, and CentOS Linux 7 end of life on 30 June 2024, the day RHEL 7 reached the end of its maintenance phase. That post also reminded readers to migrate containers, not just hosts, a point that is still easy to miss.

Two projects form in parallel

Within days, two efforts started. Gregory Kurtzer, whom the RESF board page describes as the founder of CentOS, started Rocky Linux; a comment on the CentOS blog post on 11 December 2020 already pointed at the rocky-linux/rocky repository on GitHub. A separate team started AlmaLinux, which is now stewarded by the independent AlmaLinux OS Foundation described below.

The two projects took slightly different paths to a first release. AlmaLinux published a beta of 8.3 on 1 February 2021 and its first stable release on 30 March 2021. Rocky Linux's documentation lists 8.3 on 1 May 2021, and the project declared general availability with 8.4 on 21 June 2021; the 8.4 announcement refers to the release candidate that came before it. In the 8.4 announcement, the RESF said the project set out to build an operating system "bug-for-bug compatible with the upstream Enterprise Linux standard" and stressed that its sources, build infrastructure and Git repositories were public so anyone could fork the work.

Who governs AlmaLinux and Rocky Linux

The AlmaLinux OS Foundation

The AlmaLinux OS Foundation describes itself as "a registered 501(c)(6) organization under US law" and publishes its US tax ID. A 501(c)(6) is a business league or trade association form, which is why the foundation notes that contributions are typically not tax deductible as charitable gifts. The foundation says it exists to keep the distribution "community-governed" through elected leadership and public minutes, with "a structure no single sponsor can capture". It publishes bylaws, board operations and ethics rules, and membership terms. Technical direction sits with ALESCo, the AlmaLinux Engineering Steering Committee, which also approves patches that ship ahead of upstream.

The Rocky Enterprise Software Foundation

Rocky Linux is the flagship project of the Rocky Enterprise Software Foundation. The RESF says its principles include that it "will never be driven, motivated, or manipulated by profit or monetary gain" and that its projects use only OSI-approved open source licences. Its About page lists the board: Gregory Kurtzer as President and Chair, described as "Founder of CentOS, Rocky Linux, and other open source projects", plus directors and independent members including Christopher DiBona and Theodore Ts'o, and named leads for Rocky Linux architecture, engineering and operations. The RESF FAQ addresses questions such as whether the RESF is a non-profit, whether Kurtzer owns it and whether Rocky Linux belongs to a commercial company; those answers are worth reading directly before you cite the legal structure in a vendor review, because the RESF governance model is different from a classic member foundation.

Why governance belongs in your risk register

For most teams, the governance question is practical: who decides when the distribution changes direction, and could one company change the rules again the way CentOS Linux 8 was cut short? Neither foundation can promise that upstream sources stay available on today's terms, because both depend on code that Red Hat writes and publishes. What they can control is how they respond, and the June 2023 episode showed both doing so within days.

Release timeline: every 8.x, 9.x and 10.x release

The authorities are the AlmaLinux release notes wiki and the Rocky Linux releases documentation. The older Rocky wiki version guide now says its content "is now moved" to the documentation site; where the two disagree, the table uses the documentation site.

Major versions and support end dates

AlmaLinux states the same windows on its release notes page: version 8 "active support until 31 May 2024, and security support until 31 May 2029", version 9 until 31 May 2027 and 31 May 2032, version 10 until 31 May 2030 and 31 May 2035. Rocky's documentation states Rocky 9 has "general support until 31 May 2027 and security support through 31 May 2032", and Rocky 10 the same pattern to 2030 and 2035. Both sets of dates track RHEL's ten year life cycle, which places major releases in May and minor releases every May and November.

Minor releases side by side

AlmaLinux names each minor release after a wild cat. Rocky Linux names each major release after a stone and does not name minor releases. Kernel versions are the ones each project lists at release.

A few patterns stand out. First, AlmaLinux has usually shipped a few days before Rocky Linux. RHEL 10 reached general availability on 20 May 2025, AlmaLinux 10.0 followed seven days later and Rocky Linux 10.0 22 days later. Second, the kernel package release numbers sometimes differ at release (9.5, 9.6, 9.8, 10.0 and 10.2 in the table), which reflects which kernel update each project had built into its release media, not a different kernel line. Third, the 9.0 gap of about seven weeks between the two projects is the largest in the table.

The two Rocky sources do not fully agree. The older wiki table gives 15 May 2022 for 8.6, 11 November 2022 for 8.7, 20 May 2023 for 8.8 and kernel 5.14.0-570.17.1 for 9.6; the documentation site gives 16 May, 14 November, 19 May and 570.18.1. The table above uses the documentation site, which the wiki itself points to as current. None of these one to three day differences changes a support decision.

AlmaLinux also ships AlmaLinux OS Kitten 10, released 22 October 2024 with kernel 6.11.0-25. Kitten is built from CentOS Stream 10 and is AlmaLinux's development preview; its active support "will match the end of CentOS Stream 10". It is not a long term support release and should not appear in production inventories as if it were AlmaLinux 10.

Architecture differences that change your fleet plan

Rocky's 10.0 announcement calls the move to x86-64-v3 "the most significant change in Rocky Linux 10" and says "All 32-bit packages have been removed". AlmaLinux's release table lists x86_64_v2 alongside x86_64 for every 10.x release, and marks i686 as "userspace only, no bootable installer and no 32-bit kernel". Rocky's documentation lists only x86_64 and aarch64 for Rocky 8, and x86-64-v2, aarch64, ppc64le and s390x for Rocky 9. If part of your fleet runs on older processors that do not meet the x86-64-v3 level, this single row may decide which distribution you can run on version 10.

What changed after June 2023

Red Hat's source availability change

On 21 June 2023, Red Hat published Furthering the evolution of CentOS Stream. It said "CentOS Stream will now be the sole repository for public RHEL-related source code releases" and that for Red Hat customers and partners, "source code will remain available via the Red Hat Customer Portal". It explained that Red Hat had kept pushing RHEL sources to git.centos.org even after CentOS Linux stopped being built downstream, and that maintaining those separate repositories no longer fit its priorities.

For rebuilds, this removed the public stream of RHEL source RPMs they had been importing. CentOS Stream code is close to RHEL, but it is not identical to a given RHEL minor release on a given day. A rebuild that promises to match RHEL exactly needs RHEL's own sources.

Rocky Linux: keep bug-for-bug, change the source path

Rocky moved first. On 24 June 2023, Brave New World: The Path Forward for Rocky Linux said the project had noticed it was "about ten updates behind" the week before, had completed update composes for Rocky Linux 8 and 9 including all the missing updates and errata, and was using its Peridot build system to automate the extra imports. It also said a public transparency ledger of SRPMs, patches and checksums was "in the works".

On 29 June 2023, Keeping Open Source Open described the two source routes Rocky would use: RHEL Universal Base Image (UBI) container images, and "pay-per-use public cloud instances" from which anyone can obtain RHEL source packages through DNF. The post said these routes rely on the GPL's redistribution rights and that the project's legal advisers had reassured it. Rocky kept its bug-for-bug goal.

AlmaLinux: move to ABI compatibility

AlmaLinux chose a different path. On 13 July 2023 the foundation's board chair, benny Vasquez, published the announcement, and the FAQ summarises it: "In July of 2023, we announced that we were shifting our goal from being a downstream rebuild of RHEL to maintaining ABI compatibility with RHEL." The announcement post explained the consequence plainly: AlmaLinux would "no longer be held to the line of bug-for-bug compatibility" and could "accept bug fixes outside of Red Hat's release cycle". It defined binary or ABI compatibility as ensuring that applications built to run on RHEL can run without issue on AlmaLinux, including kernel compatibility. The FAQ adds that "everything from software applications to kernel modules that work on RHEL will work on AlmaLinux, and if they don't we would consider that a bug". AlmaLinux also began adding comments to its patches that link to where each patch came from.

What the difference means in practice

Bug-for-bug and ABI compatible sound similar, but they produce different artefacts:

The practical consequence for security teams is that "matches RHEL" is no longer a safe shortcut for AlmaLinux. If AlmaLinux has shipped a fix ahead of Red Hat, a scanner that only reads Red Hat's data will report a host as vulnerable when it is not. The AlmaLinux security page lists examples of patches the project shipped or offered for testing ahead of upstream, including fixes related to the XZ backdoor and regreSSHion (CVE-2024-6387), and says critical issues reported to the linux-distros mailing list "are patched on the date of disclosure". Read your distribution's own advisories, not only its upstream's.

OpenELA

A third response came from three companies that formed the Open Enterprise Linux Association (OpenELA). Its FAQ calls it "a non-profit trade association of open source Enterprise Linux distribution developers" and names the founding organisations: CIQ, Oracle and SUSE. OpenELA defines "Enterprise Linux" as "1:1 and bug-for-bug source code compatibility which today is aligned to RHEL and CentOS". It publishes source code, not a binary distribution, so that downstream distributions can build from it. Its project list includes the Enterprise Linux sources, a maintained Linux 4.14 long term branch, the Leapp upgrade tool, Mothership (tools to archive RPM sources and attest to their authenticity) and ELValidated, a compatibility test suite.

OpenELA is not either foundation, and none of the AlmaLinux or Rocky Linux release documents cited here names OpenELA as a package source. CIQ, an OpenELA founder, is the company the Rocky Linux 8.4 announcement named for paid commercial support, which is why the two are often mentioned together. If you depend on a specific source path for compliance reasons, ask the distribution where a given package's sources came from rather than inferring it from membership lists.

How packages are built, signed and published

AlmaLinux: ALBS, signed packages and SBOMs

AlmaLinux builds packages in the AlmaLinux Build System (ALBS), an open source build service. Its security page lists a "Verifiable supply chain" with "Signed packages and a Software Bill of Materials you can check". Every package is signed with a GPG key and dnf verifies the signature by default. The current release keys, from the AlmaLinux security page:

The AlmaLinux 8 entry is labelled as the second AlmaLinux 8 key and dates from 10 October 2023. If an old AlmaLinux 8 host or image fails signature checks after a long gap, check that this key is installed before anything else.

The AlmaLinux SBOM user guide explains that the build system records build metadata in an append-only, tamper-evident database (immudb) and that the alma_sbom.py tool can produce an SBOM for a build ID or for a package hash. It supports CycloneDX and SPDX, in JSON or XML. The guide's example produces a CycloneDX JSON record for build 17812. This is per build and per package provenance data that lets you trace an installed RPM back to the build that produced it; it is not an SBOM of your whole server, which you still need to generate yourself from the installed package database.

AlmaLinux also states that AlmaLinux OS 9.2 carries FIPS 140-3 validated cryptographic modules on the NIST CMVP Active list and is certified under Common Criteria, and that it supports Secure Boot with a shim signed by Microsoft.

Rocky Linux: Peridot, Apollo and release keys

Rocky Linux builds with Peridot, its own open source build system, which the June 2023 post credits with automating the extra source imports. Errata come from Apollo, which the Rocky wiki errata page says works "together with the build system peridot" and "replaces the old errata system secparse", generating the updateinfo.xml data that dnf reads. Rocky's package signing and testing guide says RPMs "should be cryptographically signed with a Rocky Linux key, which guarantees to users that the package was indeed built by the Rocky Linux project".

The Rocky Linux keys page lists the release keys and shows how to compare a key file on disk with gpg --quiet --show-keys:

Rocky's documentation does not describe a per package SBOM output equivalent to AlmaLinux's tool. The transparency ledger promised in June 2023 was described as showing SRPMs, applied patches and checksums; check the project's current documentation before you rely on it as an attestation source.

How security errata flow

Advisory types and naming

Both projects mirror Red Hat's advisory numbering, so RHSA-2022:6159 becomes RLSA-2022:6159 in Rocky and ALSA-2022:6159 in AlmaLinux when the same fix is rebuilt.

The AlmaLinux errata wiki explains that ALSA is "considered the most important type as it contains security fixes" and recommends the errata.full.json files over the older errata.json schema. The AlmaLinux security page links public OVAL streams for versions 8, 9 and 10 and an OSV database.

Rocky's errata page lists an errata browser, the Apollo API, its OpenAPI specification and an RSS endpoint. The OSV schema ecosystem list registers both prefixes: RLSA and RXSA for the "Rocky Linux Security Advisory Database", with an OSV formatted URL on apollo.build.resf.org, and ALSA, ALBA and ALEA for AlmaLinux, with the source URL on errata.almalinux.org.

How long after Red Hat do fixes land?

Neither project promises a contractual SLA. Rocky's version guide sets expectations: updates "are generally expected to be built and released between twenty-four (24) and fourty-eight (48) hours" after upstream, assuming the packages build cleanly, and minor releases "at least a week (7 days) after upstream". Major releases "have no guaranteed ETA". AlmaLinux's security page describes its process rather than a number: it follows upstream for most patches, applies ALESCo-approved patches ahead of upstream when the community needs them, aims to acknowledge direct reports within two to three days and patches critical issues from the linux-distros list on the disclosure date.

In practice, expect most important fixes within a day or two of Red Hat's advisory, with occasional longer gaps when a package needs new build dependencies, and with the June 2023 week as a reminder that source supply can stall.

Minor version end of life is the trap

Both projects support only the newest minor release of each major version. AlmaLinux says "Each minor version reaches end of life when the new version is released", and Rocky's documentation says "No minor release is supported past the release of the next minor release". When 9.8 ships, 9.7 packages move to the vault and receive nothing more. A host pinned to releasever=9.7, or a container built FROM a 9.7 tag, stops getting fixes on the day 9.8 is released, even though "Rocky Linux 9" or "AlmaLinux 9" is supported until 2032. Neither project's documentation describes support for older minor releases, the gap Red Hat fills with paid Extended Update Support.

Comparison: RHEL, CentOS Stream, AlmaLinux, Rocky Linux and Oracle Linux

Notes on the table: Red Hat's RHEL 10 launched on 20 May 2025 according to its press release. CentOS Stream 8 ended builds on 31 May 2024, matching RHEL 8.10. Oracle's Linux support page says Premier Plus, Premier and Basic Support "are available for ten years from the release date of a major Oracle Linux release", followed by Extended Support and lifetime Sustaining Support. Red Hat's product life cycle data gives RHEL 8 full support to 31 May 2024 and maintenance support to 31 May 2029, RHEL 9 to 31 May 2027 and 31 May 2032, and RHEL 10 to 31 May 2030 and 31 May 2035, with a paid Extended Life Cycle Support add-on running four more years (to 2033, 2036 and 2039). AlmaLinux and Rocky Linux use exactly the same full support and maintenance end dates, and offer no equivalent of the ELS add-on. We have not verified Oracle's advisory prefix or source path on an Oracle document for this post; treat those cells as pointers, not citations.

Step by step: verify, migrate and check for updates

The commands below were taken from each project's documentation. Run them on a test host first.

Step 1: verify an AlmaLinux ISO

AlmaLinux signs its CHECKSUM file with the release key, so you can check both integrity and origin. From the AlmaLinux installation guide:

# Import the AlmaLinux 9 release key
curl -O https://repo.almalinux.org/almalinux/RPM-GPG-KEY-AlmaLinux-9
gpg --import RPM-GPG-KEY-AlmaLinux-9

# Download the signed checksum list and check its signature
curl -O https://repo.almalinux.org/almalinux/9/isos/x86_64/CHECKSUM
gpg --verify CHECKSUM
# Expect: Good signature from "AlmaLinux OS 9 <packager@almalinux.org>"
# Then compare the primary key fingerprint with:
# BF18 AC28 7617 8908 D6E7 1267 D36C B86C B86B 3716

# Hash the ISO and compare with the signed list
sha256sum AlmaLinux-9.8-x86_64-dvd.iso
grep 'SHA256 (AlmaLinux-9.8-x86_64-dvd.iso)' CHECKSUM

gpg will warn that the key "is not certified with a trusted signature". That warning is normal for a freshly imported key. What matters is that the fingerprint matches the one on almalinux.org, fetched over HTTPS from the project's site, not from the mirror that served the ISO.

Step 2: verify a Rocky Linux ISO

Rocky's installation guide uses the checksum file directly:

wget -O CHECKSUM https://download.rockylinux.org/pub/rocky/10/isos/x86_64/CHECKSUM
sha256sum -c CHECKSUM --ignore-missing
# Expect a line such as: Rocky-10.2-x86_64-minimal.iso: OK

A matching hash proves the ISO matches the checksum list, not that the list itself came from Rocky. Download CHECKSUM from download.rockylinux.org over HTTPS rather than from the same mirror as the ISO, and after installation compare the installed key with the fingerprint on the keys page:

gpg --quiet --show-keys /etc/pki/rpm-gpg/RPM-GPG-KEY-Rocky-10
# Expect: FC226859C0860BF0DDB95B085B106C736FEDFC85

Step 3: migrate an existing EL host to AlmaLinux

Warning: a distribution migration replaces signed packages, the kernel and bootloader entries on a running system. Take a snapshot or full backup first, confirm you are on the intended host, and check that /boot has free space before you start.

# Confirm which host and release you are about to change
hostnamectl
cat /etc/os-release
df -h /boot

# Update the current system first
sudo dnf update -y

# Download and run AlmaLinux's migration script
curl -O https://raw.githubusercontent.com/AlmaLinux/almalinux-deploy/master/almalinux-deploy.sh
less almalinux-deploy.sh        # read it before running it as root
sudo bash almalinux-deploy.sh

# Reboot into the AlmaLinux kernel and confirm
sudo reboot
cat /etc/redhat-release

The AlmaLinux migration guide lists the systems the tool converts: CentOS 8, CentOS Stream 8, 9 and 10, Oracle Linux 8, 9 and 10, RHEL 8, 9 and 10, Rocky Linux 8, 9 and 10, and others, including hosts with common hosting control panels. The minimum supported EL8 version is 8.4, so upgrade older 8.x hosts first. Migrating a CentOS Stream host to AlmaLinux can mean moving to slightly older package versions, because Stream runs ahead; plan for that.

Step 4: migrate an existing EL host to Rocky Linux

Warning: the same backup, host check and /boot space check apply here.

hostnamectl
cat /etc/os-release
df -h /boot

sudo dnf install -y git
git clone https://github.com/rocky-linux/rocky-tools.git
cd rocky-tools/migrate2rocky/
less migrate2rocky.sh            # use migrate2rocky9.sh on a 9.x system
chmod u+x migrate2rocky.sh
sudo ./migrate2rocky.sh -r

# After the reboot, confirm
hostnamectl
cat /etc/rocky-release

The migrate2rocky guide explains that the scripts live in the rocky-tools repository and that 9.x systems use migrate2rocky9.sh. The guide says the -r option "tells the script to go ahead and install everything", that a "Complete!" message means the conversion finished, and that you should restart the server and check the result with hostnamectl.

Step 5: check pending security updates

Both distributions read advisories from updateinfo.xml:

# Summary of advisories that apply to this host
dnf updateinfo

# Every applicable advisory, with its ID, severity and package
dnf updateinfo list

# Only security advisories, only Important or Critical
dnf updateinfo list --security --sec-severity=Important --sec-severity=Critical

# Details for one advisory
dnf updateinfo info RLSA-2022:6159     # Rocky
dnf updateinfo info ALSA-2022:6159     # AlmaLinux

# Which CVE does an advisory fix, and is it applied?
dnf updateinfo list --cve CVE-2024-6387

# Apply only security updates
sudo dnf upgrade --security

Rocky's errata page shows sample output in which dnf updateinfo reports a security update installed but a different kernel still running. That is a reminder that installing a kernel update does nothing until the host reboots. Use dnf needs-restarting -r (from dnf-utils or dnf-plugins-core) to check.

Step 6: confirm you are on a supported minor release

cat /etc/almalinux-release    # or /etc/rocky-release
rpm -E %{rhel}                  # major version
dnf repolist -v | grep -i baseurl
grep -r releasever /etc/dnf/vars/ /etc/yum.repos.d/ 2>/dev/null

If releasever is pinned to a minor version, or a repository URL points at a vault path, the host is no longer receiving fixes. Remove the pin and run sudo dnf upgrade to move to the current minor release.

Common mistakes

• Treating "9" as supported when the host is on 9.6. Only the latest minor release of each major version gets updates. A golden image frozen at an old minor release ages out silently.
• Assuming AlmaLinux package versions equal RHEL's. Since July 2023, AlmaLinux can ship patches ahead of Red Hat. A scanner that maps AlmaLinux to RHEL data may raise false positives; one that ignores AlmaLinux errata may miss AlmaLinux-only fixes.
• Comparing upstream version numbers. Enterprise Linux backports fixes. openssh-8.7p1 with an ALSA or RLSA fix applied can be safe even though upstream fixed the issue in a later release. Compare against the distribution's advisory, not the upstream changelog.
• Moving a Rocky 9 workload to Rocky 10 on older hardware. Rocky Linux 10 requires x86-64-v3. On a current EL9 host, /lib64/ld-linux-x86-64.so.2 --help | grep x86-64-v lists which levels the CPU supports; run it on the target hardware before you plan the upgrade.
• Forgetting containers. The CentOS Linux 7 end of life post said it plainly: migrate your containers, not just your hosts. FROM centos:7 images still exist in many registries.
• Trusting the mirror for the checksum. A checksum file served by the same mirror as the ISO proves nothing about origin. Check the signature or fingerprint against the project's own site.
• Running a migration script without reading it. Both scripts change repositories, keys and the kernel as root. Read them, run them on a snapshot first and keep the console handy.
• Treating Kitten as AlmaLinux 10. AlmaLinux OS Kitten tracks CentOS Stream and ends with it. It is a preview channel, not a ten year release.
• Assuming OpenELA membership tells you where packages come from. Neither AlmaLinux nor Rocky Linux describes OpenELA as its source. Ask the project.

FAQ

When does Rocky Linux 8 reach end of life?

Rocky Linux 8 reaches end of life on 31 May 2029. Its active support ended on 31 May 2024 with the 8.10 release, which is the final minor version. Until 2029 it receives security and maintenance updates only.

When does AlmaLinux 9 reach end of life?

AlmaLinux 9 has active support until 31 May 2027 and security support until 31 May 2032. The current release is 9.8 from 26 May 2026, and 9.9 is in beta.

Is AlmaLinux or Rocky Linux the direct replacement for CentOS?

Both were created to replace CentOS Linux as a free RHEL-compatible distribution, and both provide migration scripts from CentOS 8. Rocky Linux aims for bug-for-bug compatibility with RHEL; AlmaLinux aims for ABI compatibility. CentOS Stream is the CentOS Project's continuing product, but it runs ahead of RHEL rather than matching it.

What is the difference between bug-for-bug and ABI compatible?

Bug-for-bug compatible means the distribution tries to ship exactly what RHEL ships, including its unfixed bugs. ABI compatible means software and kernel modules built for RHEL run unchanged, but the distribution may fix bugs or add patches before RHEL does.

Did Rocky Linux release before AlmaLinux?

No. AlmaLinux 8.3 became stable on 30 March 2021. Rocky Linux's release table lists 8.3 on 1 May 2021, and the project announced general availability with 8.4 on 21 June 2021, an announcement that refers back to an earlier release candidate.

What does RLSA mean, and what does ALSA mean?

RLSA is a Rocky Linux Security Advisory and ALSA is an AlmaLinux Security Advisory. Both usually reuse the number of the matching Red Hat advisory (RHSA), so RLSA-2022:6159 and ALSA-2022:6159 fix the same issue as RHSA-2022:6159.

How quickly do Rocky Linux and AlmaLinux release security fixes after Red Hat?

Rocky's documentation says updates are generally built and released within 24 to 48 hours of upstream when the build is clean. AlmaLinux does not publish a number but says it follows upstream for most patches and patches critical issues from the linux-distros list on the disclosure date.

Can I upgrade Rocky Linux 9 to Rocky Linux 10 in place?

The AlmaLinux-led ELevate project says it supports in-place upgrades "from 9.x to 10.x within the same distribution", using the open source Leapp utility plus a data library called leapp-data, and that it is designed for one-step upgrades. Test it on a snapshot first. Many teams rebuild instead, which also gives you a clean image and an SBOM that matches it. Remember that Rocky 10 needs x86-64-v3 hardware.

What is OpenELA and is Rocky Linux part of it?

OpenELA is a non-profit trade association founded by CIQ, Oracle and SUSE that publishes Enterprise Linux source code for downstream distributions. It does not ship a binary distribution. Rocky Linux and AlmaLinux are governed by their own foundations, and neither describes OpenELA as its source.

Does AlmaLinux publish SBOMs?

AlmaLinux's build system produces SBOM data per build, and its alma_sbom.py tool outputs CycloneDX or SPDX in JSON or XML for a build ID or package hash. That covers how a package was built. You still need your own SBOM of each server or image to know what is installed.

Choosing a ten year enterprise Linux base only covers the operating system packages that AlmaLinux or Rocky Linux build and sign. The application dependencies and container layers you add on top, from Python wheels to Java libraries, are yours to patch, and they are where most images carry the largest share of unfixed issues. A rebuilt Rocky or AlmaLinux image pulls all of those dependencies again on every build, so the habits below matter as much as dnf upgrade --security.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The local runner demo shows how to set up a runner on your own machine, approve it with its device code and start a scan from the terminal. On an AlmaLinux or Rocky Linux build host, the same flow lets you scan a directory, an SBOM or a built image, for example safeguard scan --image against an image built FROM a Rocky or AlmaLinux base, and keep the results under ./output as JSON.

Click through it at your own pace, or open it full screen.

The Safeguard CLI demo is a real session: the assistant reads a finding and its advisory, asks before each command, edits package.json to move lodash to 4.17.21, runs npm install and npm test with your approval and pushes nothing. The same ask before you act pattern applies when an application layer on top of an enterprise Linux image needs a dependency bump, while the OS packages themselves come from dnf upgrade --security.

Click through it at your own pace, or open it full screen.

The Claude with Safeguard demo shows how to connect Claude to the Safeguard MCP server with OAuth and choose which tools Claude can use. Once connected, you can ask which of your projects contain a given component and version and which findings apply to them, which is a quick way to find every project still carrying a package from a minor release that has left support.

Click through it at your own pace, or open it full screen.

To try it on your own images, download Safeguard and follow the CLI documentation.

Quick check

Sources

• CentOS Blog: CentOS Project shifts focus to CentOS Stream (December 2020)
• CentOS: CentOS Linux EOL
• CentOS Blog: End dates are coming for CentOS Stream 8 and CentOS Linux 7 (2023)
• Red Hat: Furthering the evolution of CentOS Stream (21 June 2023)
• Red Hat: Red Hat introduces RHEL 10 (20 May 2025)
• AlmaLinux Wiki: Release Notes
• AlmaLinux Wiki: FAQ
• AlmaLinux: The future of AlmaLinux is bright (July 2023)
• AlmaLinux OS Foundation
• AlmaLinux: Security
• AlmaLinux Wiki: Errata
• AlmaLinux Wiki: SBOM user guide
• AlmaLinux Wiki: Installation guide (ISO verification)
• AlmaLinux Wiki: Migration guide
• AlmaLinux repository: AlmaLinux 9 x86_64 ISO CHECKSUM
• Rocky Linux Documentation: Rocky Releases
• Rocky Linux Wiki source: Release and Version Guide
• Rocky Linux Wiki source: Errata
• Rocky Linux: Rocky Linux 8.4 GA Available Now (21 June 2021)
• Rocky Linux: Rocky Linux 9.0 Available Now (14 July 2022)
• Rocky Linux: Rocky Linux 10.0 Available Now (11 June 2025)
• Rocky Linux: Brave New World, The Path Forward for Rocky Linux (24 June 2023)
• Rocky Linux: Keeping Open Source Open (29 June 2023)
• Rocky Linux: Keys
• Rocky Linux Documentation: Installing Rocky Linux
• Rocky Linux Documentation: migrate2rocky
• Rocky Linux Documentation: Package signing and testing
• Rocky Linux download mirror: Rocky 9 x86_64 ISO CHECKSUM
• Rocky Enterprise Software Foundation
• RESF: About and board
• RESF: FAQ
• OpenELA: News
• AlmaLinux: ELevate
• AlmaLinux Wiki: ELevate
• Red Hat: Product life cycles, Red Hat Enterprise Linux
• Red Hat: Product life cycles API, Red Hat Enterprise Linux
• Red Hat: Red Hat Enterprise Linux life cycle
• OpenELA
• OpenELA: FAQ
• OSV schema: ecosystem and prefix list
• Oracle: Oracle Linux support

Last reviewed: 24 October 2026. Minor release numbers and dates change every May and November; check each project's release notes before planning an upgrade.