The Day the Ground Shifted
December 8, 2020 is a date that carries the weight of consequence for anyone who has ever run production workloads on Linux. Red Hat, then under IBM ownership, announced that CentOS Linux -- the free, stable, downstream rebuild of Red Hat Enterprise Linux (RHEL) that had quietly powered an enormous fraction of the world's servers for over sixteen years -- would be discontinued. Not phased out slowly. Not transitioned with adequate runway. CentOS 8, which was barely three months old at the time of the announcement, would reach end of life at the end of 2021 instead of the originally promised 2029. Eight years of expected support, evaporated in a press release.
The reaction from the systems administration and DevOps community was immediate, visceral, and justifiably angry. CentOS was not a niche product used by hobbyists. It was the invisible backbone of web hosting companies, university research clusters, government servers, financial platforms, and scientific computing facilities worldwide. The abrupt change left organizations running production workloads on an operating system that would soon receive no security patches, with no graceful migration path and no comparable free alternative in sight.
Into that vacuum, multiple actors moved fast. But only one emerged with the institutional structure, the technical credibility, and the philosophical clarity to become the genuine heir to CentOS's legacy: AlmaLinux.
Origins: From Project Lenix to a Soul
CloudLinux Inc., a company with roots in server-hardened Linux distributions for the web hosting industry, recognized the implications of Red Hat's announcement immediately. Its CEO, Igor Seletskiy, made a decision within days. CloudLinux's own commercial product, CloudLinux OS, was itself built upon CentOS source code and was effectively an enterprise-hardened variant of RHEL. The CentOS announcement was not merely inconvenient for CloudLinux -- it was existential.
Seletskiy kicked off an initiative to build a 1:1 binary compatible fork of RHEL that would be free to use and open source, giving it the internal code name Project Lenix. The name was later changed when the team reflected more on what they were building and why. On January 12, 2021, Project Lenix was renamed AlmaLinux.
The naming choice was deliberate and meaningful. The word "alma" is derived from the Latin "almus," meaning "nourishing, kind," and also carries the meaning "soul" in Spanish and Italian. The name was chosen as an explicit homage to the Linux community itself -- the idea that a community of developers, administrators, and organizations could collectively be the soul of an operating system, rather than any single corporate entity.
The speed of execution was remarkable. A beta version of AlmaLinux was first released on February 1, 2021, and the first stable release was published on March 30, 2021. That is less than four months from Red Hat's announcement to a production-grade operating system available for public use. For context, major Linux distribution releases often take years of coordinated effort.
CentOS succeeded because it solved a genuine structural problem in enterprise computing: organizations needed RHEL-compatible stability without RHEL subscription costs. Web hosting companies in particular built entire ecosystems around CentOS -- cPanel, Plesk, and virtually all major hosting control panels were tested and certified against it. University and national laboratory computing clusters ran CentOS because it was the closest they could get to a supported enterprise OS without budget line items for commercial licenses.
When Red Hat ended CentOS 8 support early, the timeline mismatch was critical. CentOS 8 had been released in September 2019 with a promised lifecycle extending to 2029. Organizations that standardized on it for new deployments in 2019 and 2020 had made infrastructure decisions based on that commitment. The December 2020 announcement gave them roughly one year to migrate an unknown number of production systems -- systems that, in many cases, could not simply be re-imaged without coordinated maintenance windows, regression testing, and ISV re-certification. The anger was not merely about inconvenience. It was about trust: the community had made commitments based on Red Hat's commitments, and those commitments were broken unilaterally.
CentOS Stream, the replacement Red Hat offered, operates upstream of RHEL rather than downstream -- it is a continuous-delivery preview of the next RHEL point release. For organizations running production infrastructure, this is not equivalent to a stable, long-lived LTS release. Stream receives updates that have not yet been validated against RHEL's full QA cycle, making it unsuitable for environments that require stability and predictability above feature recency.
Governance: The Non-Profit Architecture as Technical Decision
One of the consequential and underappreciated aspects of AlmaLinux's story is not a kernel patch or a package version -- it is the legal and governance structure chosen from the very beginning. This was not an afterthought. It was a foundational architectural decision with direct implications for the distribution's long-term technical stability.
To ensure the independence, transparency, and longevity of the project, the AlmaLinux OS Foundation was created as a US non-profit 501(c)(6) organization on March 30, 2021 -- the same day as the first stable release of AlmaLinux. On that date, CloudLinux formally transferred responsibility for development and governance to the Foundation, which became the legal owner of all AlmaLinux assets. (Some sources cite March 18, 2021 as an incorporation date; the Foundation's official account and Wikipedia confirm March 30 as when the handover and public launch occurred simultaneously.)
Why does this matter technically? Because governance structure directly affects build pipeline stability, release scheduling predictability, and the ability to make independent technical decisions. An operating system controlled by a single commercial entity can have its roadmap altered by a board meeting, a hostile acquisition, or a quarterly earnings report. AlmaLinux's Foundation model means that no single sponsor -- not even CloudLinux, which committed to $1 million per year in annual funding -- can unilaterally redirect the project.
You will find two conflicting narratives about AlmaLinux governance in online communities, and both need to be addressed directly because they each contain something true.
The concern: CloudLinux founded AlmaLinux, provides $1 million per year in funding, and its commercial arm TuxCare (which is a division of CloudLinux, not a separate company) provides the FIPS 140-3 validated packages and developed the DISA STIG. Critics argue this concentration of influence -- founding, funding, and commercializing compliance tools for the same distribution -- represents a structural conflict that the 501(c)(6) wrapper does not fully resolve. The RESF (which governs Rocky Linux) explicitly cited this pattern as a reason it chose a Delaware Public Benefit Corporation instead of a 501(c)(6), arguing that 501(c)(6) structures can allow board influence to be tied to financial contributions in ways that a PBC's bylaws can more cleanly prohibit.
What the AlmaLinux bylaws actually say: The Foundation's own bylaws explicitly state that entities cannot "buy their way" onto the board. Individual membership is free, and any individual who uses AlmaLinux, contributes to it, or supports it qualifies for membership without a financial contribution. Corporate sponsors join as Sponsor members and can participate on committees, but board membership is governed by member elections, not by donation tier. The Foundation held its first community-elected board in September 2022, after which CloudLinux CEO Igor Seletskiy stepped down from the board specifically to demonstrate that CloudLinux does not control the Foundation. The board's current membership includes representatives from CERN, Cybertrust Japan, Meta Platforms, and others with no CloudLinux affiliation.
The Rocky Linux governance comparison: Rocky Linux is governed by the Rocky Enterprise Software Foundation (RESF), a Delaware Public Benefit Corporation -- not a tax-exempt 501(c) non-profit. The RESF describes itself as a "self-imposed not-for-profit," which is a genuine governance philosophy, not a marketing claim, but it does not carry the same IRS accountability as a 501(c) organization. The RESF bylaws cap any single company's voting board representation at one-third. Neither structure provides an absolute guarantee against future corporate influence. What matters in practice is the actual people involved, the transparency of decisions, and the track record of each organization when community and sponsor interests have conflicted. Both projects have, to date, demonstrated meaningful community governance.
Our position on this guide: We report the Foundation's legal structure and its practical governance mechanisms accurately. The CloudLinux/TuxCare relationship is a legitimate area of scrutiny that readers should be aware of, and we have not minimized it. At the same time, the structural safeguards in the bylaws -- free individual membership, member-elected board, documented separation of CloudLinux from Foundation control -- are real and publicly verifiable. Readers should weigh both.
The AlmaLinux OS Foundation holds open elections with free individual membership available to any community contributor. Board members from institutions including CERN, Cybertrust Japan, Meta Platforms, and Fujitsu subsidiary Fsas Technologies have joined its governing board. This is a legally enforceable structure designed to ensure that the community, not capital, steers the system -- though as with any governance model, the proof is in the ongoing practice, not the structure alone.
The AlmaLinux Build System: Reproducibility as a Core Value
To understand what makes AlmaLinux technically distinct, you need to look under the hood at how it is built -- not just what it contains.
AlmaLinux is built using publicly-viewable and reproducible methods using the AlmaLinux Build System (ALBS), which is a customized build system whose source code, like the distribution itself, is publicly distributed and licensed under open-source licenses.
ALBS was first used in production to build AlmaLinux 8.6, released in May 2022, and was publicly released as open source under the GPLv3 license. The build system is available at build.almalinux.org, providing anonymous, read-only access so that anyone can see what packages are being built right now, when a particular package was built, when a package build fails, and all the logs associated with the build process for each and every package.
Architecturally, ALBS consists of five core components operating under a Master Service API:
The Git Service acts as a source code listener. It monitors changes to source code repositories that comprise RHEL, pulls those sources to AlmaLinux's own publicly-accessible Gitea server instance, and exposes an API for the rest of the build pipeline to consume.
The Build Node is where compilation happens. Build Node is designed for the automated building of RPM packages, uses Docker and docker-compose for deployment, and supports x86_64, aarch64, and ppc64le architectures. It prepares a specially isolated environment -- for RPM packages, the mock utility creates the build chroot -- and handles creating source RPMs from SPEC files, applying patches, and uploading artifacts to the Artifact Storage system (PULP).
The Sign Server handles cryptographic signing of packages. Every package that ships in AlmaLinux carries a cryptographic signature that allows users to verify the package's authenticity and integrity. This is a critical security control that prevents supply chain attacks.
The Test System runs automated validation against built packages before they are released. This is where the quality gate lives.
The Release System orchestrates the final publication of packages to the mirror network.
This end-to-end transparency from source code intake to signed package publication is what allows AlmaLinux to make a credible claim about the provenance of every binary it ships. In an era when supply chain security has become a front-page concern -- SolarWinds, XZ Utils, and similar incidents have demonstrated what happens when build pipelines are opaque -- AlmaLinux's approach deserves serious attention from anyone responsible for enterprise infrastructure.
SBOM Integration: Package-Level Supply Chain Provenance
Beyond build log transparency, ALBS integrates a full Software Bill of Materials (SBOM) pipeline into every package it produces -- a capability that is increasingly mandated by regulation but that few Linux distributions have operationalized at this depth. AlmaLinux stores its SBOM data in Codenotary's immudb, a cryptographically verifiable, append-only immutable database. Each stage of the build process -- source intake, compilation, signing, testing -- undergoes authentication and notarization, creating a tamper-evident chain of trust from source to signed package.
The security property that makes immudb meaningful rather than just convenient is that no one, including AlmaLinux itself, can retroactively alter or delete an SBOM record once it has been written. Each record is cryptographically chained. This is not a policy guarantee -- it is an architectural one. immudb encrypts its data structure such that any modification would produce a detectable inconsistency in the chain. This means the trust model does not require you to trust AlmaLinux's good intentions; it requires only that you trust the cryptographic properties of the database. The encryption key is client-side verified before every communication, and the system is designed to resist MITM attacks.
The Foundation has developed a dedicated utility called alma-sbom that generates SBOM records in both CycloneDX and SPDX formats (JSON or XML), and allows administrators to verify that any installed package is notarized and trusted by querying the immudb instance with the package's build ID or RPM hash. This means you can independently verify that a package you received matches the build record, and that the record has not been modified after the fact.
The forensic dimension is the one that gets the least attention: in the event of a supply chain compromise, this architecture provides certainty about when a tampered package entered the pipeline. If a malicious package somehow reached an AlmaLinux mirror, the immudb record would establish the exact build timestamp and source commit at which the compromise occurred, making incident response and scope determination significantly faster than on distributions where build provenance relies on log files that can be altered. This contrasts with the SolarWinds model, where the build pipeline was opaque enough that the compromise went undetected for months and the scope took weeks to establish.
No other free enterprise Linux distribution provides this combination: public, real-time build logs with anonymous access, plus per-package SBOMs stored in a cryptographically immutable database. It also satisfies the US Executive Order 14028 SBOM mandate and the EU Cyber Resilience Act Art. 13 requirements, meaning organizations running AlmaLinux can generate per-package provenance documentation as part of their standard compliance workflow rather than as a bolted-on afterthought.
It is worth noting that AlmaLinux was among the first Enterprise Linux distributions to integrate SBOM generation directly into its build pipeline. The 9.2 kernel's FIPS 140-3 Entropy Source Validation was the first software implementation to receive a FIPS 140-3 ESV certificate using SHA3-256 as a conditioner -- a technical detail that demonstrates the project's willingness to push ahead of even its upstream on specific security capabilities.
Architecture Support: Where AlmaLinux Outpaces Competitors
One of the technically substantive differentiators between AlmaLinux and comparable distributions is its architecture support matrix. AlmaLinux officially supports four CPU architectures:
x86_64 -- the standard 64-bit Intel and AMD architecture used in the vast majority of server hardware.
aarch64 -- 64-bit ARM, increasingly critical for cloud-native workloads on AWS Graviton instances, Azure Ampere Altra instances, and bare-metal ARM servers.
ppc64le -- IBM Power architecture in little-endian mode. This architecture powers IBM's POWER8, POWER9, and POWER10 processors, which are heavily used in financial services, insurance, and high-performance transaction processing environments. AlmaLinux added ppc64le support in AlmaLinux 8.5, released in February 2022, ahead of several competitors.
s390x -- IBM Z mainframe architecture. This is the architecture that runs the world's banking systems, airline reservation systems, and core financial infrastructure. The s390x support means that organizations running IBM Z infrastructure can use AlmaLinux as a free enterprise operating system in those environments.
| Architecture | Hardware | Use Case | AlmaLinux Support Since |
|---|---|---|---|
x86_64 |
Intel/AMD 64-bit | Standard servers, cloud instances, workstations | 8.3 (March 2021) |
aarch64 |
ARM 64-bit | AWS Graviton, Azure Ampere, ARM servers | 8.4 (May 2021) |
ppc64le |
IBM POWER (LE) | Financial services, transaction processing | 8.5 (February 2022) |
s390x |
IBM Z mainframe | Banking, airline reservations, core finance | 8.6 (May 2022) |
x86-64-v2 |
Older Intel/AMD (SSE4.2+) | Legacy hardware, extended lifecycle servers | 10.0 (May 2025) |
In AlmaLinux 10, the architecture support story became even more interesting. The project introduced an x86-64-v2 baseline build alongside the default x86-64-v3 baseline. RHEL 10 targets x86-64-v3, which requires AVX and other extensions present in processors manufactured roughly from 2013 onward. AlmaLinux 10, however, builds EPEL packages to support users on older hardware that cannot support v3 instructions. This is not a trivial technical decision. It represents the project team listening to real operational constraints -- the reality that enterprise hardware refresh cycles span years or decades -- and making a specific engineering choice to accommodate them.
The 2023 Inflection Point: ABI Compatibility and the Source Code Crisis
The smoothest version of AlmaLinux's story ended in June 2023. That month, Red Hat announced that CentOS Stream would become the sole repository for RHEL-related source code, and that the full RHEL source code would only be available to paying subscribers. This was a legal and technical shock to the entire ecosystem of RHEL-compatible downstream distributions.
The implications were stark. Prior to this change, AlmaLinux and other RHEL rebuilds could access the SRPM (Source RPM) files that Red Hat was legally required to publish under the GPL and similar licenses. These SRPMs allowed distributions to compile exact binary-compatible copies of RHEL's packages. After the change, Red Hat argued that while they remained in compliance with open-source licenses by providing source code to customers, they were no longer obligated to provide it to the general public in the same accessible format.
benny Vasquez, board chair of the AlmaLinux Foundation, announced the project's response: AlmaLinux would drop the aim of being 1:1 with RHEL and instead aim for Application Binary Interface (ABI) compatibility.
This was a philosophically significant and technically nuanced decision. 1:1 binary compatibility means that every compiled binary in AlmaLinux is byte-for-byte identical (or functionally identical including bugs) to its counterpart in RHEL. This was the original goal and the gold standard for CentOS-style rebuilds. ABI (Application Binary Interface) compatibility operates at a different layer. An ABI defines the interface at which compiled machine code interacts with the operating system and with other compiled code. It specifies calling conventions, data structure layouts, symbol names, system call numbers, and library interfaces. ABI compatibility means that a compiled binary built for RHEL will execute correctly on AlmaLinux -- not because the underlying libraries are byte-identical, but because the interfaces those libraries expose are functionally equivalent.
The ABI vs. 1:1 compatibility debate is one of the most discussed topics in enterprise Linux communities, and the online discourse around it contains real technical disagreement as well as tribalism. Here is what the debate actually looks like and what is factually settled versus genuinely uncertain.
What is factually settled: AlmaLinux publicly announced the shift to ABI compatibility in July 2023 and Rocky Linux did not. AlmaLinux builds primarily from CentOS Stream sources. Rocky Linux rebuilds from RHEL source code accessed via cloud images, UBI containers, and other mechanisms. These are documented facts, not opinions.
What practitioners report: A large portion of the enterprise Linux practitioner community reports no functional difference between running RHEL-compiled workloads on AlmaLinux versus Rocky Linux. Databases, web servers, containerized applications, and most enterprise software stacks run identically on both. The benny Vasquez interview with Linux Magazine (2024) quoted AlmaLinux's own position: users chose AlmaLinux for ease of use, security, stability, and sponsor diversity -- not for byte-identical RHEL compatibility. The pivot responded to what users had told them they actually needed.
Where the distinction is real: ISV (Independent Software Vendor) certifications are earned against RHEL specifically. If your software vendor's support contract explicitly requires RHEL or a byte-identical rebuild, ABI compatibility may not satisfy that clause. Some formal compliance frameworks and government procurement documents specify RHEL by name. In these narrowly defined cases, the distinction between ABI and 1:1 binary compatibility has genuine operational consequences. Rocky Linux's argument that 1:1 binary compatibility provides stronger guarantees for these scenarios is technically coherent, not a marketing claim.
Our position on this guide: We report the distinction accurately without minimizing it. For the vast majority of workloads, ABI compatibility is sufficient and the practical difference is negligible. For regulated environments with explicit binary compatibility requirements in their compliance documentation, the distinction matters and should be investigated before deployment. We do not resolve this debate for you -- we give you the information to evaluate it yourself.
For organizations with compliance requirements that specifically mandate RHEL binary compatibility, the distinction between 1:1 and ABI compatibility has real consequences. Red Hat's certification programs and ISV software certifications are built around RHEL. AlmaLinux's ABI compatibility claim is meaningful but has not been validated through the same certification processes.
Crucially, the pivot also unlocked something that 1:1 compatibility had prevented: the ability to ship fixes independently of Red Hat's release cycle. The first demonstration of this new capability came almost immediately. In July 2023, AlmaLinux shipped patches for the Zenbleed vulnerability -- a speculative execution bug affecting AMD Zen 2 processors -- ahead of Red Hat's equivalent release. This was the first time AlmaLinux moved faster than its upstream on a security issue, demonstrating that the ABI compatibility model was not merely a defensive retreat but an active expansion of capability.
The ABI compatibility vs. 1:1 binary compatibility debate matters most in two specific scenarios: ISV software certification and government/regulated-industry compliance documentation. For ISV certifications, Red Hat maintains a hardware and software compatibility list that vendors test against RHEL specifically. When an ISV says their software is "RHEL certified," that certification was earned on actual RHEL binaries, not ABI-compatible alternatives. In practice, the software almost certainly runs fine on AlmaLinux -- but the vendor's support contract may explicitly exclude non-RHEL deployments, meaning you carry the support risk yourself.
For compliance documentation, some frameworks and auditing standards require explicit OS identification. A compliance document that says "RHEL 9" does not automatically extend to AlmaLinux 9, even with ABI compatibility. Whether auditors accept AlmaLinux as equivalent depends heavily on the specific framework, the auditor's interpretation, and whether your organization's authorizing official has approved the substitution. DISA STIGs, CIS benchmarks, and PCI-DSS all have slightly different postures on this. The AlmaLinux DISA STIG (published February 2025) makes this somewhat cleaner for DoD environments, but it still requires authorizing official sign-off.
For the vast majority of workloads -- web servers, databases, container orchestration, application hosting, data processing pipelines -- ABI compatibility is entirely sufficient. The practical difference manifests primarily at the intersection of commercial support contracts, formal ISV certifications, and compliance documentation that explicitly names RHEL. If none of those apply to your deployment, the ABI vs. binary debate is largely academic.
ELevate: The In-Place Migration Framework
One of the practically impactful pieces of infrastructure AlmaLinux has contributed to the broader Enterprise Linux ecosystem is a tool called ELevate. Announced in September 2021, ELevate addresses one of the most expensive and disruptive aspects of enterprise Linux management: major version upgrades.
Historically, upgrading a RHEL-family server from one major version to another required a complete reinstallation. This meant rebuilding from scratch, migrating configurations manually, retesting applications, and coordinating maintenance windows -- a process that could take days per server and was prohibitively expensive at scale.
ELevate is built on top of Red Hat's own Leapp upgrade framework, extending it to work across distributions and across major version boundaries. The tool is developed in a distribution-agnostic way and is built as a tool for the whole ecosystem, not just AlmaLinux. ELevate supports migrating to and from other distributions and is open for all to contribute to and enhance.
# Step 1: Fully update the system and reboot (required before ELevate) $ sudo yum update -y && sudo reboot # Step 2: Install the ELevate release package # $(rpm --eval %rhel) dynamically resolves to the source OS major version (7, 8, or 9) $ sudo yum install -y http://repo.almalinux.org/elevate/elevate-release-latest-el$(rpm --eval %rhel).noarch.rpm # Step 3: Install Leapp with AlmaLinux migration data $ sudo yum install -y leapp-upgrade leapp-data-almalinux # Step 4: Run the pre-upgrade assessment (expected to report inhibitors -- review and resolve them) $ sudo leapp preupgrade # Step 5: Review /var/log/leapp/leapp-report.txt, resolve all inhibitors, then upgrade $ sudo leapp upgrade # Step 6: Reboot -- system boots into the ELevate-Upgrade-Initramfs environment automatically $ sudo reboot # Step 7: After reboot, verify the upgrade completed successfully $ cat /etc/redhat-release && cat /etc/os-release
The project has facilitated upgrades on over 500,000 devices worldwide. The technical mechanism works as follows: Leapp analyzes the current system state, builds a transaction list of packages to be replaced, creates a minimal upgrade initramfs environment, reboots into that environment to perform the package replacement at a system level where the running OS is not holding file locks, and then boots into the upgraded system. ELevate extends this pipeline with distribution-specific data mappings that handle the differences in package naming, repository structure, and branding between vendors. In January 2024, ELevate expanded to include support for additional repositories, and in April 2024, the project added support for upgrading from CentOS 6 to CentOS 7, making it possible to chain upgrades from CentOS 6 all the way through to a current Enterprise Linux 9-family distribution.
What makes ELevate remarkable from a strategic standpoint is the decision to build it as a community tool rather than an AlmaLinux-proprietary tool. For its first four years, ELevate supported migrations to Rocky Linux as well as AlmaLinux. As of November 3, 2025, Rocky Linux migration data is no longer included in ELevate's stable release following format changes in leapp-repository 0.23.0 -- the required Rocky Linux migration data has not been contributed by the community. ELevate continues to support AlmaLinux, CentOS Stream, and other distributions whose migration data is maintained.
Two additional milestones in late 2025 are worth noting. In November 2025, ELevate gained support for upgrading to AlmaLinux OS 10 and AlmaLinux OS Kitten 10, enabling the full upgrade chain from CentOS 7 through to EL 10. Then in December 2025, ELevate was accepted into the upstream LEAPP project itself -- meaning AlmaLinux and CentOS Stream upgrade paths are now maintained in the LEAPP codebase that Red Hat itself develops, significantly reducing the maintenance burden for the ELevate project. This history reflects the AlmaLinux project's stated philosophy: the health of the enterprise Linux ecosystem matters more than market share.
Scientific Endorsement: CERN, Fermilab, and the Physics of Enterprise Linux
Perhaps the most significant external validation of AlmaLinux's technical credibility came when CERN and Fermilab announced they would standardize on AlmaLinux. CERN began moving to AlmaLinux in 2022 following the CentOS end-of-life situation, and the formal board representation followed in December 2023 when Alejandro Iribarren joined the Foundation's governing board.
CERN is not a typical organization. It operates the Large Hadron Collider, generates petabytes of data from particle physics experiments annually, and requires an operating system that is simultaneously stable enough to support years-long experimental runs and flexible enough to handle the computational demands of analyzing subatomic collision data. Their Linux platform choices are informed by rigorous technical testing, not marketing relationships.
Alejandro Iribarren (known as Alex), Tech Lead of the Linux Platform Engineering group at CERN, subsequently joined the AlmaLinux OS Foundation's board of directors in December 2023, alongside Jun Yoshida of Cybertrust Japan. This is governance integration with real institutional stakes -- not an advisory role.
The CERN decision had downstream effects. It validated AlmaLinux for any organization that applies scientific-computing-grade standards to their infrastructure decisions. High-energy physics computing environments are among the most demanding in the world for operating system stability, security update frequency, and package compatibility. If AlmaLinux can power LHC experiments, it can power the majority of enterprise production environments.
AlmaLinux 10 and the Kitten: A Dual-Track Development Model
In October 2024, AlmaLinux announced something genuinely novel in the RHEL ecosystem: AlmaLinux OS Kitten 10, a separate preview distribution based on CentOS Stream 10 sources rather than RHEL 10.
This dual-track approach reveals a sophisticated understanding of the new upstream relationship. CentOS Stream is the development preview for RHEL -- packages appear in Stream before they appear in the stable RHEL release. Kitten allows AlmaLinux to begin building against these pre-release sources, giving users an earlier view of what AlmaLinux 10 will contain while also allowing the project to identify and fix issues before the stable RHEL 10 release.
The stable AlmaLinux 10.0 "Purple Lion" release shipped on May 27, 2025, introducing several features that differentiate it from RHEL 10 proper:
- SPICE support re-enabled -- Simple Protocol for Independent Computing Environments had been unsupported since RHEL 9.0. AlmaLinux users requested support back, and it is fully re-enabled in AlmaLinux OS 10 for both server and client applications.
- Post-quantum cryptography -- support for NIST-standardized algorithms. In AlmaLinux 10.0, the OpenSSL toolkit and OpenSSH suite gained support for post-quantum algorithms. In AlmaLinux 10.1, OpenSSL 3.5 introduced the finalized NIST standards: ML-KEM (Module-Lattice Key Encapsulation Mechanism, previously known as CRYSTALS-Kyber) for key encapsulation, ML-DSA (Module-Lattice Digital Signature Algorithm, previously CRYSTALS-Dilithium) for digital signatures, and SLH-DSA (Stateless Hash-based Digital Signature Algorithm, previously SPHINCS+). Note: you will see both the original algorithm names and the NIST-finalized names used interchangeably in documentation online. The finalized names reflect NIST's formal standardization in FIPS 203, 204, and 205 published in 2024.
- KVM for IBM Power -- introduced as a tech preview of KVM virtualization support for the IBM Power architecture in AlmaLinux 10.0, allowing continued use of libvirt and KVM as in AlmaLinux 8. The tech-preview designation was dropped in AlmaLinux 10.1, where KVM for IBM POWER is fully enabled in the virtualization stack.
- 150+ device drivers re-enabled -- drivers for hardware that Red Hat dropped to optimize its support matrix, directly serving government, academic, and industrial environments with constrained hardware refresh cycles. This practice began in AlmaLinux 8.10 and 9.4 and continues in AlmaLinux 10, where the same driver PCI IDs (covering storage controllers, Fibre Channel HBAs, and network adapters from Adaptec, Dell PERC, HP Smart Array, IBM ServeRAID, QLogic, Emulex, Mellanox, and Broadcom) are re-added to each release.
- x86-64-v2 architecture -- AlmaLinux 10.0 introduced a secondary x86-64-v2 architecture build alongside the default x86-64-v3 baseline required by RHEL 10, providing a path for older hardware that lacks AVX support. In AlmaLinux 10.1, ALESCo approved rebuilding EPEL packages for x86-64-v2 users, extending the secondary build's utility beyond the base OS package set to the full EPEL ecosystem. Neither the v2 build nor the EPEL v2 rebuilds are available in RHEL 10 itself.
- Btrfs filesystem support -- added in AlmaLinux 10.1 "Heliotrope Lion" (November 24, 2025), including kernel and userspace enablement with the ability to install AlmaLinux on Btrfs from the start. Initial enablement is scoped to the installer and storage management stack; broader Btrfs feature support across the software collection is planned for future updates.
Post-quantum cryptography (PQC) is relevant today, even though cryptographically relevant quantum computers do not yet exist, because of a threat model known as "harvest now, decrypt later" (HNDL). Nation-state adversaries and sophisticated threat actors are already collecting encrypted network traffic in bulk, storing it, with the intent to decrypt it retroactively once quantum computing capability matures. For data that must remain confidential for 10-15 years -- classified government communications, long-term medical records, proprietary financial data, intellectual property -- traffic encrypted today with classical algorithms like RSA or ECDH could be decryptable in that timeframe.
The NIST post-quantum standards finalized in 2024 (FIPS 203 ML-KEM, FIPS 204 ML-DSA, FIPS 205 SLH-DSA) are the result of an eight-year standardization process. ML-KEM provides key encapsulation (replacing ECDH/RSA for key exchange), ML-DSA provides digital signatures, and SLH-DSA provides a hash-based signature scheme with different security assumptions. AlmaLinux 10.1's inclusion of OpenSSL 3.5 with these finalized algorithms means that organizations can begin deploying hybrid classical/post-quantum TLS today, providing forward secrecy against future quantum attacks without abandoning classical security guarantees in the present.
The practical deployment path in OpenSSH involves the sntrup761x25519-sha512 hybrid key exchange (combining NTRU Prime with X25519), which has been available in OpenSSH since version 8.5 and is the default in recent versions. AlmaLinux 10's OpenSSH supports this out of the box. For organizations under NSA CNSA 2.0 guidance or preparing for FedRAMP post-quantum requirements, AlmaLinux 10.1 provides the cryptographic stack needed to begin that transition without sourcing packages from third-party repositories.
Security Model: Errata, SELinux, and SCAP Compliance
AlmaLinux's security architecture is one of the areas where it clearly outperforms its predecessor CentOS, and where it provides value that is often overlooked in casual comparisons.
CentOS famously did not provide security errata metadata in a machine-readable format. This meant that automated security patch management tools -- systems that query for and apply only security-critical patches -- could not function properly. System administrators had to apply all available updates indiscriminately or maintain manual tracking of which packages addressed which vulnerabilities.
AlmaLinux provides full updateinfo metadata with each package update, allowing commands like dnf update --security to work correctly -- applying only packages that address CVEs without forcing non-security updates that might require their own testing and maintenance windows.
Errata Advisory Taxonomy and OVAL Streams
AlmaLinux's errata system uses a three-prefix advisory classification that many administrators are not aware they can filter on: ALSA (AlmaLinux Security Advisory) for security fixes, typically corresponding to MITRE/NIST-assigned CVEs; ALBA (AlmaLinux Bug Advisory) for bug fixes, which can include security-relevant corrections; and ALEA (AlmaLinux Enhancement Advisory) for enhancements and feature additions. Each advisory is ranked by severity: Critical, Important, Moderate, and Low. This taxonomy enables precise automated patch management -- for example, a production environment can be configured to auto-apply only ALSA advisories rated Critical or Important, while batching lower-severity updates for scheduled maintenance windows. AlmaLinux also publishes OVAL (Open Vulnerability and Assessment Language) streams for versions 8, 9, and 10, providing machine-readable vulnerability definitions that integrate with OpenSCAP, Nessus, Tenable, and other compliance scanning tools. The AlmaLinux errata database is additionally indexed in Google's OSV (Open Source Vulnerabilities) database, enabling automated vulnerability correlation across the entire open-source supply chain.
DISA STIG: Department of Defense-Grade Hardening
In February 2025, DISA (the Defense Information Systems Agency) officially published a Security Technical Implementation Guide (STIG) for AlmaLinux OS 9 -- making it the first RHEL clone to receive a version 9 DISA STIG, ahead of both Oracle Linux and Rocky Linux. Oracle Linux 9 received its own DISA STIG a few months later (initial submission April 2025, finalized May 2025, now at V1R4), while Rocky Linux still does not have a DISA STIG for any version. The STIG contains 443 security controls (as of v1r5) based on NIST SP 800-53, covering mandatory practices including SmartCard authentication, LUKS full-disk encryption, USBGuard enforcement, and FIPS cryptographic module usage. The STIG was developed over roughly a year of collaboration between TuxCare engineers and DISA, and is now at revision v1r5 (as of March 2026) with Ansible and SCAP automation available for automated compliance scanning.
There are two sources of confusion about the AlmaLinux DISA STIG that lead to contradictory descriptions online. Both are worth clarifying explicitly.
The naming confusion: "official" vs. "TuxCare-developed." The STIG was developed by TuxCare engineers (TuxCare being a division of CloudLinux, the founding sponsor of AlmaLinux). TuxCare submitted it to DISA, and DISA then officially reviewed, accepted, and published it to the DoD Cyber Exchange at public.cyber.mil. Once DISA publishes a STIG, it carries DISA's official authority -- the fact that a third party submitted the underlying work is standard practice, not a disqualifier. The published STIG name is "CloudLinux AlmaLinux OS 9 Security Technical Implementation Guide," which preserves the naming from TuxCare's submission but is listed in DISA's official catalog. Earlier versions of this guide incorrectly described the STIG as "unofficial" -- that was wrong, and we corrected it. The STIG is officially published by DISA.
The operational confusion: "having a STIG" vs. "being approved for DoD use." A published DISA STIG means the document exists and can be used. It does not automatically mean your specific AlmaLinux deployment is approved for use on DoD networks. DoD deployments still require an Authorizing Official (AO) sign-off, and some agencies may require that the system use the TuxCare FIPS 140-3 validated packages as a companion requirement to the STIG (since the STIG mandates FIPS cryptography). Organizations do not need to be part of the US government to use a STIG -- it represents the highest publicly-available level of security hardening guidance -- but government users should verify current acceptance status with their AO before treating STIG availability as approval for production deployment.
Secure Boot: Air-Gapped Key Generation and the 2026 Certificate Transition
AlmaLinux has supported UEFI Secure Boot since version 8.4, with its shim bootloader officially signed by Microsoft. The AlmaLinux shim currently trusts two certificates issued through Sectigo, both signed for the AlmaLinux OS Foundation. The Foundation's Secure Boot key generation process follows an air-gapped security protocol documented publicly in the AlmaLinux wiki: keys are generated on a machine that is never connected to the internet, stored on FIPS 140-certified self-destructing USB hardware (devices that physically destroy their contents if brute force or disassembly is attempted), and distributed to key holders via GPG-encrypted transfers. Unlock codes for the hardware-encrypted drives are provided separately through the Foundation's internal Vaultwarden password manager or GPG-encrypted email. Keys must be stored offline in fire-resistant safes or bank safety deposit boxes.
In February 2026, AlmaLinux updated its shim to version 16.1, which introduced a critical architecture-specific change: the x86_64 shim continues to use the original Microsoft Windows UEFI Driver Publisher key from 2011, while the aarch64 (ARM64) shim has been switched to the new Microsoft UEFI CA 2023 key. This transition is significant because the original Microsoft 2011 UEFI signing certificates begin expiring in June 2026. After that date, new installation media must use shims signed with the 2023 key. Systems with firmware databases lacking the 2023 certificate will need firmware updates from their hardware vendors to boot new Linux installation media with Secure Boot enabled. This is not just an AlmaLinux issue -- it affects every Linux distribution that relies on Microsoft's UEFI third-party signing chain -- but AlmaLinux proactively addressed the ARM64 transition ahead of the expiration deadline.
# Install OpenSCAP scanner and the SCAP Security Guide content package $ sudo dnf install -y openscap-scanner scap-security-guide # Apply only security-critical updates $ sudo dnf update --security # List available security advisories $ sudo dnf updateinfo list --security # Show details for a specific advisory $ sudo dnf updateinfo info ALSA-2026:6799 # List all available profiles in the AlmaLinux 10 data stream $ oscap info /usr/share/xml/scap/ssg/content/ssg-almalinux10-ds.xml | grep -A1 "Profile" # Run an OpenSCAP compliance scan against CIS Level 2 Server benchmark # Use the full profile ID -- short aliases vary by oscap version $ sudo oscap xccdf eval \ --profile xccdf_org.ssgproject.content_profile_cis \ --results /tmp/cis-results.xml \ --report /tmp/cis-report.html \ /usr/share/xml/scap/ssg/content/ssg-almalinux10-ds.xml # For CIS Level 1 Server (less restrictive, suitable for most production servers) $ sudo oscap xccdf eval \ --profile xccdf_org.ssgproject.content_profile_cis_server_l1 \ --results /tmp/cis-l1-results.xml \ --report /tmp/cis-l1-report.html \ /usr/share/xml/scap/ssg/content/ssg-almalinux10-ds.xml
SELinux is shipped in enforcing mode by default in AlmaLinux, consistent with RHEL. Running SELinux in permissive mode is common in environments where administrators find policy tuning difficult, but it provides no security enforcement. AlmaLinux's default enforcing posture means that a compromised application process is constrained by policy even if it manages to escalate to root within its context.
OpenSCAP integration provides automated compliance scanning against security benchmarks. AlmaLinux ships production-ready OpenSCAP profiles for CIS benchmarks, DISA STIG, PCI-DSS, and HIPAA-relevant profiles. These profiles allow organizations subject to regulatory compliance requirements to perform automated assessment and remediation. AlmaLinux 9.2 achieved FIPS 140-3 certification and is on the NIST Active list -- with important clarifications worth stating plainly: the FIPS 140-3 validated packages for AlmaLinux 9.2 are provided through TuxCare's Extended Security Updates offering (a CloudLinux division), not through the base AlmaLinux OS packages from the Foundation. TuxCare covered the certification costs -- nearly $400,000 in fees and effort -- and provides the validated kernel (CMVP certificate #4750), OpenSSL (certificate #4823), GnuTLS, NSS, and Libgcrypt packages. The AlmaLinux 9.2 kernel was the first EL9-family distribution to receive a FIPS 140-3 certificate for the kernel, and the project's entropy source validation was the first software implementation to receive a FIPS 140-3 ESV certificate using SHA3-256 as a conditioner (providing 256-bit entropy compared to the previous standard 64-bit LFSR implementation). As of late 2025, AlmaLinux 9.6 is advancing through the validation pipeline with all four cryptographic modules (Kernel Crypto API, OpenSSL, GnuTLS, and NSS) on NIST's "Modules in Process" list, having passed accredited lab testing and received the required CAVP/ESV certificates. Organizations requiring FIPS-validated operation should install the specific TuxCare packages following the published instructions rather than assuming the base OS installation is already FIPS-validated.
xccdf_org.ssgproject.content_profile_stig included in base scap-security-guidexccdf_org.ssgproject.content_profile_pci-dss included in base SSG package includedupdateinfo OVAL streams. Use dnf update --security for CVE-only patching to reduce change risk during PCI audits.auditd present by default. Configure ausearch / aureport for audit trail requirements.auditd provides access control logging meeting HIPAA access control requirements.xccdf_org.ssgproject.content_profile_cis_server_l1 -- suitable for most production servers includedxccdf_org.ssgproject.content_profile_cis -- more restrictive; may break some applications. Test before deploying to production.scap-security-guide Ansible content.dnf update --security for security-only patches. Filter by ALSA severity (Critical, Important) using dnf updateinfo list --security.AlmaLinux vs. Rocky Linux: A Technical and Philosophical Comparison
The post-CentOS landscape is dominated by two distributions -- AlmaLinux and Rocky Linux -- and comparing them requires honesty about both their technical differences and their philosophical divergences.
Both distributions emerged from the same crisis with the same stated goal: provide a free, stable, enterprise-grade operating system in the RHEL ecosystem. Both have succeeded in building real communities and achieving meaningful adoption. But they have made different choices.
On the governance question, AlmaLinux's 501(c)(6) non-profit structure contrasts with Rocky Linux's Delaware Public Benefit Corporation. This is a genuine area of debate online, and both sides make reasonable arguments. AlmaLinux's 501(c)(6) is a tax-exempt, legally audited structure with open community elections. Rocky's RESF, while not a 501(c) non-profit, is a self-described "self-imposed not-for-profit" PBC that argues the 501(c)(6) model can actually introduce corporate capture risk through the ability to sell board influence. The RESF specifically cited this as a reason they chose the PBC structure. Neither argument is unreasonable. What matters in practice is the actual governance practices each organization maintains -- the people involved, the transparency of decisions, and what happens when there is a conflict between a major sponsor and the community. Both organizations have, so far, demonstrated meaningful community governance.
On the compatibility question, the 2023 Red Hat source code crisis created a fork in approaches. Rocky Linux chose to maintain 1:1 binary compatibility by finding alternative ways to access RHEL source code -- mining sources from cloud images, UBI containers, and other mechanisms, and continues to claim 1:1 compatibility to this day. AlmaLinux chose the ABI compatibility path, which offers greater development flexibility but involves a philosophical and architectural departure from the original CentOS-style rebuild model. This is a genuinely contested point in the community: Rocky Linux supporters argue that their 1:1 approach provides stronger guarantees for ISV certifications and compliance requirements; AlmaLinux supporters counter that ABI compatibility is sufficient for the vast majority of workloads and that the flexibility to ship fixes ahead of Red Hat is a meaningful advantage. Both claims have merit depending on the specific use case. What is factually accurate is that AlmaLinux publicly announced the shift to ABI compatibility in July 2023 and Rocky Linux did not.
On the innovation dimension, AlmaLinux has been willing to diverge from RHEL in ways that serve users -- re-enabling dropped drivers, restoring SPICE support, shipping security fixes ahead of the upstream. Rocky Linux, committed to 1:1 compatibility, cannot make these choices without breaking its core promise.
If strict RHEL binary compatibility is a documented compliance requirement, Rocky Linux is worth evaluating given its continued 1:1 compatibility claim. If architecture breadth, transparent build infrastructure, post-quantum cryptography, and the ability to receive fixes ahead of Red Hat's release cycle matter, AlmaLinux makes a compelling technical case. If Oracle support contracts and integrated Oracle technology stacks are priorities, Oracle Linux deserves evaluation. For the majority of general server workloads, both AlmaLinux and Rocky Linux are functionally equivalent, and the choice often comes down to which community's governance philosophy you find more credible.
The Release History: A Distribution Growing Up
AlmaLinux's release history tells the story of a project that started in emergency response mode and matured into something with genuine architectural ambitions.
AlmaLinux 8.3 (March 30, 2021) was the emergency response -- a functional RHEL clone produced in weeks to fill the CentOS void. It shipped for x86_64 only.
AlmaLinux 8.4 (May 30, 2021) added ARM64 (aarch64) support, Secure Boot, and production-ready OpenSCAP profiles.
AlmaLinux 8.5 (February 25, 2022) added ppc64le support, two new repositories (ResilientStorage and Plus), enhanced Cockpit integration, and Network Time Security (NTS).
AlmaLinux 9.0 (May 26, 2022) was the first release based on RHEL 9, delivering Python 3.9, OpenSSL 3.0, nftables as the default firewall backend, and Cockpit improvements.
AlmaLinux 10.0 "Purple Lion" (May 27, 2025) introduced post-quantum cryptography support in OpenSSL and OpenSSH, SPICE re-enablement, a secondary x86-64-v2 architecture build, KVM for IBM POWER (tech preview), and continued re-enabling device drivers dropped by RHEL.
AlmaLinux 10.1 "Heliotrope Lion" (November 24, 2025) added full Btrfs filesystem installation support, promoted KVM for IBM POWER from tech preview to fully enabled, expanded x86-64-v2 support to the EPEL package set, enabled the CRB repository by default, delivered OpenSSL 3.5 with the finalized ML-KEM/ML-DSA/SLH-DSA post-quantum algorithms, and updated developer toolsets including GCC 14.3.1, LLVM 20.1.8, and Rust 1.88.0.
Each minor release follows the naming convention of combining a color with an animal: Midnight Oncilla, Blue Flame, Emerald Puma, Sky Tiger, Teal Serval, Cerulean Leopard, Lime Lynx. The names are whimsical, but the underlying substance is serious.
Special Interest Groups: How Community-Driven Development Actually Works
AlmaLinux's SIG (Special Interest Group) structure is one of the underappreciated mechanisms that differentiates it from distributions governed by a single company's product roadmap. As of early 2026, the project maintains at least thirteen active SIGs: Core, Build System, Cloud, Infrastructure, Migration, Live Media, Marketing, Certification, AltArch, and -- the ones that reveal the project's strategic direction -- HPC and AI, Atomic, and Media and Entertainment.
The HPC and AI SIG, launched in May 2024, is led by Hayden Barnes, HPE's Senior Open Source Community Manager for AI Software. Its founding members include engineers from MEGWARE (a German HPC cluster manufacturer), LIP (the Laboratory of Instrumentation and Experimental Particle Physics in Portugal), and others operating production HPC environments. The SIG's first concrete action was a formal vote to draft a letter to NVIDIA requesting official AlmaLinux support for CUDA drivers -- a practical demonstration that SIGs are not just discussion forums but decision-making bodies that take action on behalf of the community. For organizations running GPU-accelerated workloads, the presence of an active HPC SIG backed by institutional participants like HPE and European research labs is a meaningful signal about the distribution's trajectory in scientific and AI computing.
The Atomic SIG, formed in 2025, is building something genuinely novel in the enterprise Linux space: an immutable, container-native desktop based on bootc (bootable containers). Using OCI images and OSTree, the Atomic SIG produces GNOME and KDE desktop images for AlmaLinux 10 that receive atomic updates -- the entire root filesystem is replaced as a single transaction, with instant rollback to the previous image if anything fails. The base images are published to quay.io/almalinuxorg/ and can be extended using standard OCI container tooling. The SIG also maintains a GitHub template repository that allows anyone to build a custom Atomic AlmaLinux respin with minimal effort. Downstream projects have already emerged: HeliumOS (an immutable desktop distribution), stillOS (a GNOME-based atomic desktop with web-app integration), and Querencia Linux (a MATE-based atomic desktop that packaged 128 MATE packages for EL10 from scratch). The EU OS proof-of-concept project, exploring Linux desktops for European government use, explicitly listed AlmaLinux's immutable images as a candidate technology alongside Fedora Atomic spins. The practical implication is that AlmaLinux is no longer just a server distribution -- it is becoming a platform for immutable infrastructure at both the server and desktop layers.
AlmaLinux also integrates upstream CentOS SIG repositories, making packages from CentOS SIGs (Cloud, Virtualization, Kmod, and others) directly installable on AlmaLinux. This interoperability is deliberate -- the project actively encourages contributors to submit their work to the CentOS upstream SIGs rather than maintaining AlmaLinux-only forks, further reinforcing the ecosystem-first philosophy.
The Atomic SIG's work on bootc-based immutable images represents a convergence of two major infrastructure trends: the shift to container-native deployment models and the growing security case for immutable operating systems. In an immutable OS model, the root filesystem is read-only during normal operation. Software is installed by building a new OCI image layer, not by running package manager commands on a running system. Updates are atomic: the system boots into the new image, and if something fails, it rolls back to the previous image automatically. Configuration drift -- one of the most persistent sources of security vulnerabilities and operational inconsistency in traditional server fleets -- becomes structurally impossible.
The enterprise security case is compelling. A system that cannot be modified at runtime is significantly harder to persist malware on. Rootkits that modify system binaries, persistence mechanisms that plant files in /usr or /lib, and configuration tampering attacks all require a writable root filesystem. An immutable system defeats these attack classes at the OS layer rather than relying solely on detection. SELinux enforcing mode provides the same principle at the process level; immutability extends it to the filesystem level.
The downstream AlmaLinux Atomic projects -- HeliumOS, stillOS, Querencia Linux, and the EU OS proof-of-concept -- demonstrate that the Atomic SIG's work is already being pulled into production use cases. The EU OS project's interest is particularly significant: it represents governments evaluating whether European public-sector IT can run on fully open-source, community-governed infrastructure. AlmaLinux's combination of ABI compatibility, immutable image support, DISA STIG alignment, and Foundation governance structure makes it a credible candidate for that use case in ways that RHEL (subscription cost) and Rocky Linux (no DISA STIG) are not.
Strengths and Limitations
The Strengths
AlmaLinux is completely free -- not merely "free for evaluation." There is no license tier, no feature gating, no version with commercial terms required for production use. The Foundation's explicit commitment, backed by legal structure, is that AlmaLinux will be free for as long as the community needs it.
The transparency of the build system is unmatched in the enterprise Linux space. Every package build is publicly logged. Every source is traceable. The ALBS architecture makes supply chain verification possible in a way that proprietary enterprise distributions do not.
The security infrastructure -- errata metadata, SELinux enforcing defaults, OpenSCAP profiles, Secure Boot, and post-quantum cryptography -- is production-grade from the first install without requiring additional configuration. FIPS 140-3 validation is available but requires installing TuxCare's validated package set; it is not activated by simply enabling FIPS mode on a standard install.
The architecture support is the broadest in the free enterprise Linux space, covering x86_64, aarch64, ppc64le, s390x, and x86-64-v2.
The ELevate tool provides unique value for organizations managing large fleets of aging servers, enabling in-place major version upgrades that were previously only possible through full reinstallation.
The Limitations
The shift to ABI compatibility, while technically reasonable and philosophically defensible, means that AlmaLinux can no longer be described as an exact RHEL clone. For organizations with compliance requirements that specifically mandate RHEL binary compatibility, this distinction has real consequences. It is worth noting that there is ongoing debate in the enterprise Linux community about how meaningful this difference is in practice: many practitioners report no issues running RHEL-built workloads on AlmaLinux with ABI compatibility, while others in regulated environments argue the distinction matters for ISV certifications. We report the distinction accurately because it is real, even if its practical impact varies significantly by use case. See the ABI compatibility section above for a full treatment of this debate.
The project's funding model, while more resilient than a single corporate sponsor, still depends heavily on CloudLinux's $1 million annual commitment. This raises a question that is worth naming honestly: CloudLinux founded AlmaLinux, funds it annually, and its commercial division TuxCare provides the key compliance products (FIPS 140-3 validation, DISA STIG development, CIS benchmark work) that give AlmaLinux much of its enterprise credibility. This is a high degree of influence concentration in the commercial ecosystem around the distribution, even if the Foundation's governance bylaws guard against CloudLinux controlling the board. If CloudLinux's business deteriorated significantly, the Foundation would need to rapidly expand its sponsor base. The 2024 addition of Meta Platforms and Fujitsu subsidiary Fsas Technologies as sponsors is a positive sign of diversification, but CloudLinux's position remains structurally central.
The RHEL ecosystem has inherent limitations that AlmaLinux inherits. Compared to rolling-release distributions like Arch Linux or openSUSE Tumbleweed, RHEL-family distributions carry older package versions. Developers who need bleeding-edge toolchain versions will need to supplement AlmaLinux with Software Collections, module streams, or third-party repositories.
The relatively short history of the AlmaLinux 10 branch means that its divergences from RHEL have not been tested at scale over extended production periods. The post-quantum cryptography support and re-enabled drivers are technically sound but have not accumulated the kind of production mileage that provides confidence in edge cases.
Conclusion: The Soul of Infrastructure
AlmaLinux is, at its core, an argument about who should own critical infrastructure. Not ownership in the proprietary sense -- the code is open source, the governance is public, the builds are transparent. But ownership in the sense of responsibility, accountability, and stewardship.
The systems that run the world's particle physics experiments, the web servers that host billions of web pages, the financial transaction processors that move money across borders -- these systems need operating systems that are stable, secure, transparent in their construction, and governed in a way that insulates them from the commercial pressures of any single company's quarterly earnings.
AlmaLinux does not claim to be the most innovative Linux distribution. It claims to be something rarer and harder: a genuinely free, genuinely community-owned, transparently built enterprise operating system that will still be maintained and supported when the organizations that currently fund it have long since moved on to other priorities.
Whether it succeeds in that long-term mission will depend on whether the community that benefits from it chooses to invest in its governance, contribute to its infrastructure, and hold the Foundation accountable to its stated values. The technical quality is already demonstrated. The governance structure is already in place. The production deployments at CERN, Fermilab, GitLab, and thousands of less-famous organizations are already running.
The soul, as it turns out, was a reasonable thing to name an operating system after. What endures in open-source software is not the code alone -- it is the community's willingness to keep building.
How to Evaluate and Deploy AlmaLinux in an Enterprise Environment
Step 1: Assess Your Compatibility Requirements
Determine whether your compliance and certification requirements mandate strict RHEL 1:1 binary compatibility or whether ABI compatibility is sufficient. For the majority of workloads, ABI compatibility means applications built for RHEL will run identically on AlmaLinux. Check whether your ISV certifications specifically require RHEL binaries or just RHEL-ecosystem compatibility.
Step 2: Verify Architecture and Feature Support
Confirm that your target hardware architecture is supported. AlmaLinux supports x86_64, aarch64, ppc64le, and s390x. If you are running older CPUs that do not support x86-64-v3 instructions, note that AlmaLinux 10 provides an x86-64-v2 build with EPEL package support -- a feature not available in RHEL 10 itself.
Step 3: Plan Your Migration Path
Use the ELevate tool to perform in-place major version upgrades from CentOS 7 through RHEL 8/9-family distributions to AlmaLinux. ELevate supports cross-distribution migrations and handles package replacement, repository mapping, and configuration preservation. For existing RHEL, Rocky, or Oracle Linux systems, use the almalinux-deploy script for same-version migration. For a full walkthrough of the installation process from scratch, see How to Install AlmaLinux: A Complete Guide for CentOS Refugees.
Step 4: Validate Security and Compliance Posture
After deployment, enable SELinux in enforcing mode (the AlmaLinux default), run OpenSCAP scans against the included CIS, DISA STIG, or PCI-DSS profiles, and configure dnf update --security for automated security-only patching using AlmaLinux's full updateinfo errata metadata. For a step-by-step guide to hardening a deployed system, see How to Configure AlmaLinux for Enterprise Security: SELinux, FIPS Mode, and CIS Benchmarks.
Frequently Asked Questions
What is AlmaLinux and why was it created?
AlmaLinux is a free, open-source, community-owned enterprise Linux distribution that emerged as a direct successor to CentOS after Red Hat announced CentOS Linux would be discontinued in December 2020. CloudLinux Inc. initiated the project, and the first stable release shipped on March 30, 2021. It is governed by the AlmaLinux OS Foundation, a 501(c)(6) non-profit, ensuring no single company controls its direction.
How does AlmaLinux differ from Rocky Linux?
AlmaLinux and Rocky Linux both emerged from the CentOS discontinuation but made different architectural and governance choices. AlmaLinux is governed by a 501(c)(6) non-profit Foundation and shifted to ABI compatibility with RHEL in July 2023, which allows it to ship fixes ahead of Red Hat and re-enable dropped features. Rocky Linux is governed by the Rocky Enterprise Software Foundation (RESF), a Delaware Public Benefit Corporation that self-describes as a "self-imposed not-for-profit," and continues to aim for 1:1 binary compatibility with RHEL. Both governance structures are designed to protect community interests but take different approaches. AlmaLinux also shipped s390x and ppc64le support earlier and offers tools like ELevate for cross-distribution migration. For the majority of workloads, both distributions are functionally equivalent.
What is the AlmaLinux Build System (ALBS)?
ALBS is the open-source build infrastructure used to compile all AlmaLinux packages. It was publicly released under the GPLv3 license and provides anonymous, read-only access at build.almalinux.org so anyone can see what packages are being built, when they were built, and full build logs. ALBS consists of five components: Git Service, Build Node, Sign Server, Test System, and Release System, all governed by a Master Service API.
What is ABI compatibility and how does it differ from 1:1 binary compatibility?
1:1 binary compatibility means every compiled binary is byte-for-byte identical to its RHEL counterpart, requiring access to the exact same source code and toolchains. ABI (Application Binary Interface) compatibility means that compiled binaries built for RHEL will execute correctly on AlmaLinux because the interfaces -- calling conventions, data structure layouts, symbol names, and library interfaces -- are functionally equivalent. For the vast majority of workloads, the practical difference is negligible, but ABI compatibility gives AlmaLinux the freedom to ship fixes independently of Red Hat's release cycle.
Does AlmaLinux have a DISA STIG?
Yes -- and the answer to this question is more nuanced than many online sources reflect, so it is worth being precise. DISA (the Defense Information Systems Agency) officially published the "CloudLinux AlmaLinux OS 9 Security Technical Implementation Guide" in February 2025 and it is available on the DoD Cyber Exchange at public.cyber.mil. It is at V1R5 as of March 2026. The STIG was developed by TuxCare (a division of CloudLinux) in collaboration with DISA, and TuxCare's involvement in the submission is why "CloudLinux" appears in the published name -- but the STIG itself is officially published by DISA. This is standard practice: many STIGs are submitted by vendors or third parties and published under DISA's authority. You may see older sources describing this STIG as "unofficial" or "TuxCare-maintained" -- that language predates or misrepresents the official DISA publication. Additionally, AlmaLinux ships the SCAP Security Guide (SSG) in the base OS, which includes DISA STIG-aligned, CIS, and PCI-DSS OpenSCAP profiles for automated compliance scanning. For DoD deployments, authorizing official sign-off is still required regardless of STIG availability, and some environments may require the TuxCare FIPS 140-3 validated packages as a companion requirement since the STIG mandates FIPS cryptographic module usage.
What are AlmaLinux SIGs?
AlmaLinux Special Interest Groups (SIGs) are community working groups that develop and maintain specific areas of the distribution outside the core release. As of early 2026, active SIGs include Core, Build System, Cloud, Infrastructure, Migration, Live Media, Marketing, Certification, AltArch, HPC and AI, Atomic, and Media and Entertainment. The HPC and AI SIG coordinates support for GPU-accelerated and high-performance computing workloads. The Atomic SIG builds immutable, container-native desktop images based on bootc and OSTree. SIGs are decision-making bodies and have taken concrete actions such as formally requesting NVIDIA CUDA driver support for AlmaLinux.
Sources and References
Technical details in this guide are drawn from official documentation and verified sources.
- AlmaLinux OS Foundation - Official Website -- project governance, mission, and sponsor information
- AlmaLinux Wiki - Release Notes -- release history, codenames, kernel versions, and lifecycle dates
- AlmaLinux Build System (ALBS) -- publicly accessible build pipeline and package logs
- AlmaLinux - Wikipedia -- historical timeline, governance transitions, and CERN adoption
- AlmaLinux OS 10.0 Stable Release Announcement -- AlmaLinux 10 features, SPICE re-enablement, and x86-64-v2 support
- Phoronix - AlmaLinux 2026 Goals -- project roadmap and SIG objectives for 2026
- AlmaLinux SBOM Information -- Software Bill of Materials integration, immudb storage, and CycloneDX/SPDX output
- AlmaLinux Security Measures -- errata, GPG signing, Secure Boot, OVAL, and SBOM documentation
- TuxCare - FIPS 140-3 and DISA STIG for AlmaLinux OS -- FIPS certificate details, DISA STIG publication, and CIS benchmark development
- NIST NCP - CloudLinux AlmaLinux OS 9 STIG -- official NIST National Checklist Program entry confirming DISA publication status and revision history (Initial Submission 12/19/2024, Changed Status to Final 03/24/2025, currently V1R5 as of January 2026)
- AlmaLinux Wiki - Special Interest Groups -- full SIG directory, charters, and contribution guides
- AlmaLinux Shim 16.1 Update -- Secure Boot key transition details for x86_64 and aarch64
- AlmaLinux Wiki - Secure Boot Key Generation and Handling -- air-gapped key generation SOP and FIPS-certified hardware storage