Rocky Linux

Rocky Linux is an RHEL-compatible distribution started by CentOS co-founder Gregory Kurtzer after traditional CentOS ended. It is governed by the non-profit RESF (Rocky Enterprise Software Foundation) and is today one of the two most common CentOS replacements, with Rocky Linux 9 and 10 as the current major versions.

This page is about choosing and judging: how it relates to RHEL, how the build system changed over the years, how to migrate from other systems, and which widely-repeated statements are now out of date. Installation steps are covered under Installation and Configuration and the individual task pages.

Origin Story

Gregory Kurtzer and CentOS

Gregory Kurtzer was one of the co-founders of the CentOS project. In 2004 he helped create CentOS to give the community a free RHEL-compatible distribution; he later left the project and moved into high-performance computing.

The Birth of Rocky Linux

In December 2020 Red Hat announced that CentOS Linux 8 would end early. Kurtzer announced a new project on the CentOS mailing list the same day, to continue CentOS’s original mission. The project was named Rocky Linux after the late CentOS co-founder Rocky McGaugh.

Unlike early CentOS, Rocky wrote “community-owned, non-profit governance” into its charter from day one, so that a single upstream decision could not change the distribution’s fate again.

Release Timeline

Date	Event
2020-12	Project announced
2021-04	Rocky Linux 8.3 RC released
2021-06	Rocky Linux 8.4 GA
2022-07	Rocky Linux 9.0 GA
2025-06	Rocky Linux 10.0 GA

GA and EOL dates are maintained in distro-profiles.json and by upstream announcements. This page keeps only milestones; the full lifecycle table is at the end.

Rocky Enterprise Software Foundation (RESF)

Rocky Linux is managed by the Rocky Enterprise Software Foundation (RESF), a non-profit organization that holds the Rocky trademark and infrastructure but does not hold exclusive rights to the code.

Organization Structure

RESF uses a flat, team-based structure:

Leadership Team: overall direction and decisions
Release Engineering: releases and builds
Infrastructure: build and distribution infrastructure
SIGs (Special Interest Groups): community groups by domain

Core Principles

Community-driven: decisions and contributions are open to everyone
Free to use: no subscription gate; commercial support comes from third parties
Stability first: follow RHEL’s ABI/API rather than chasing new features

RHEL Compatibility Strategy

Rocky Linux aims to be ABI/API compatible with the corresponding RHEL major version: a binary built for RHEL 9 should run on Rocky Linux 9 in the same way.

Two clarifications matter, otherwise the promise is overstated:

Compatibility is a goal and an engineering constraint, not a byte-for-byte copy. Rocky rebuilds source packages and runs compatibility checks; individual packages can still differ in behaviour, patch order or build options. For a specific problem, trust upstream announcements and Rocky’s bug tracker.
Compatibility is per major version: Rocky 9 for RHEL 9, Rocky 10 for RHEL 10. Cross-major incompatibility is a RHEL rule, not a Rocky defect.

Source Code Acquisition

Rocky’s source packages and build metadata are public, as the GPL and similar licences require:

Sources and SRPMs: git.rockylinux.org, dl.rockylinux.org
Build records and artifacts: depends on the build system (see the next section)

Compatibility Verification

Rocky maintains a compatibility suite covering:

install/upgrade/erase paths of key RPMs
default configuration and file layout of common services
ABI symbol checks against RHEL

It reduces, but does not eliminate, difference risk: self-built kernel modules, proprietary drivers, and commercial software pinned to exact versions still need vendor support matrices.

Build System: From Peridot to Koji

This is the section most often wrong in older articles. Peridot was Rocky’s own build system in the early years; since Rocky Linux 10, builds come from Koji.

Features

Peridot was Rocky’s in-house cloud-native build system during the 8/9 era:

distributed builds on Kubernetes
parallel multi-architecture builds (x86_64, aarch64, …)
public build logs and artifacts, auditable by anyone

Those properties solved the “no existing Koji infrastructure” problem at the time and made Rocky’s builds more transparent than traditional rebuild projects. It is a historical stage, not the current build system.

Why Build a Custom Build System

The original motives for building Peridot were:

independence from upstream (Red Hat/CentOS) build infrastructure
letting the community verify build results independently
supporting new architectures on Rocky’s own schedule

Rocky 10 Moves to Koji

The Rocky Linux 10 release announcement states it plainly: builds now come from Koji rather than Peridot (“Builds now come from Koji rather than Peridot”, see Rocky Linux 10.0 GA).

What that means for readers:

when looking for build records or source packages, the entry point is Koji, not Peridot;
articles that describe Peridot as the current build system predate version 10;
“open and auditable” is still true — what changed is the toolchain.

# Historical build system source (for reference only; not the current entry point)
https://github.com/rocky-linux/peridot

Migration Tools

migrate2rocky

The official scripts for moving to Rocky from another EL distribution live in the rocky-tools repository:

# EL8 -> Rocky 8
curl -O https://raw.githubusercontent.com/rocky-linux/rocky-tools/main/migrate2rocky/migrate2rocky.sh
sudo bash migrate2rocky.sh -r

# EL9 -> Rocky 9 (a different script; do not mix them up)
curl -O https://raw.githubusercontent.com/rocky-linux/rocky-tools/main/migrate2rocky/migrate2rocky9.sh
sudo bash migrate2rocky9.sh -r

Supported sources (same major version only):

CentOS Linux 8 -> Rocky 8; likewise AlmaLinux 8, Oracle Linux 8, RHEL 8 (unregister first)
AlmaLinux 9, Oracle Linux 9, RHEL 9 (unregister first) -> Rocky 9

Important: migrate2rocky is not a cross-major upgrade tool. EL8 -> EL9/EL10 is a major-version upgrade, and Rocky has no official in-place path; the approach is a fresh install plus workload migration. See EL8 to EL9 and EL9 to EL10.

Migration Notes

Take a full backup and verify restore first (the script replaces repositories and packages; rollback is expensive)
Check that third-party repositories have Rocky builds
If you use CentOS SIG repositories, confirm Rocky provides equivalents
Run dnf distro-sync after migration to align package versions
If you have a commercial support contract, confirm the vendor supports Rocky before migrating

Installation and Configuration

Getting Rocky Linux

Download portal: rockylinux.org/download

Common image types:

DVD / Boot: full installer and network boot
Minimal: minimal install
Cloud Images: GenericCloud, EC2, Azure, GCP, …
Container Images: base container images
Live Images: desktop experience

Post-Installation Setup

# Confirm distribution and version
cat /etc/rocky-release

# Update
sudo dnf update -y

# Enable CRB (CodeReady Builder; many development packages live here)
sudo dnf config-manager --set-enabled crb

# Common tools
sudo dnf install -y vim wget curl tar bash-completion

For EPEL see EPEL; for mirrors and repository configuration see Repositories.

Repository Structure

Repository	Purpose	Enabled by default
baseos	Core system packages	Yes
appstream	Applications and runtimes	Yes
crb	Developer tools and libraries	No
extras	Additional tools	Yes
highavailability	High-availability components	No
nfv	Network functions virtualisation	No
plus	Rocky-specific extras	No
rt	Real-time kernel	No

plus is Rocky’s own extra repository (off by default); enable it when you need the additional drivers or tools it carries.

Since Rocky 10, AppStream modularity is retired (no modular content is shipped), so version selection is “install the version you want” instead of module streams. See EL10 changes.

Commercial Support (CIQ)

RESF itself does not sell support. Commercial support comes from CIQ (founded by Kurtzer) and other third-party vendors. Separate the two ideas when choosing: the distribution is free, support contracts are not — you can run it without a contract, but production response times need one.

Community and Contributing

Forum and Mattermost: chat.rockylinux.org
Bugs and feature requests: git.rockylinux.org / the rocky-linux organisation on GitHub
Documentation: docs.rockylinux.org

How to Participate

Report bugs, reproduce issues, improve documentation
Join a SIG (Core, Infrastructure, Documentation, …)
Help with translation and local community work

Architecture Support

Rocky 9 covers x86_64, aarch64, ppc64le and s390x; Rocky 10 adds architectures such as RISC-V (riscv64). Whether images and packages are complete for a given architecture depends on the directory listing at dl.rockylinux.org.

SIGs (Special Interest Groups)

SIGs are community groups by domain (storage, virtualisation, HPC, cloud images, …) that own work outside the main line. Joining a SIG is one of the main ways to contribute.

Ideal Use Cases

CentOS migration: migrate2rocky within the same major version; cross-major means fresh install plus workload migration
Production servers: web, databases, application servers
Enterprise IT: RHEL-compatible systems without a subscription
Research and education: clusters and compute infrastructure
Container hosts: Podman / Kubernetes nodes

Summary

Rocky Linux’s value rests on three things: major-version ABI/API compatibility with RHEL, non-profit governance, and a public, auditable build process — the build system itself moved from Peridot to Koji, so the test for a stale claim is whether it treats the former as “current”.

Versions and Support Lifecycle

Rocky Linux version	Based on RHEL	GA	End of support	Kernel
Rocky Linux 8	RHEL 8.x	2021-06	2029-05	4.18
Rocky Linux 9	RHEL 9.x	2022-07	2032-05	5.14
Rocky Linux 10	RHEL 10.x	2025-06	2035-05	6.12

These match src/data/distro-profiles.json; lifecycle dates defer to Rocky’s announcements, and status badges are evaluated at build time. Rocky Linux 10 brings kernel 6.12, GCC 14, Python 3.12 by default and Podman 5, while the package manager remains DNF 4.20 (not DNF 5). See EL10 toolchain and EL10 changes.