CentOS Stream vs. Rebuilds: Engineering Your RHEL-Family Strategy

The Problem: The Shift from Downstream to Upstream

For years, CentOS Linux served as a free, downstream rebuild of Red Hat Enterprise Linux (RHEL). When a RHEL version was released, CentOS followed shortly after, providing a stable, binary-compatible environment for production. However, with the end-of-life (EOL) of CentOS Linux 8 in 2021 and CentOS Linux 7 in mid-2024, that model has vanished.

The project now focuses on CentOS Stream. Unlike the old CentOS, Stream is upstream of RHEL. It serves as the development platform for the next RHEL minor release. This shift creates a critical engineering decision: do you use the rolling preview (Stream), a community-led rebuild (Rocky Linux or AlmaLinux), or a direct RHEL subscription?

Thesis: Align the Distribution with the Stability Requirement

The choice depends entirely on where the system sits in your pipeline. Use CentOS Stream for development, CI/CD, and forward-compatibility testing to catch breaking changes before they hit RHEL. Use RHEL-family rebuilds (Rocky or Alma) for production workloads that require a stable, consistent environment. Use the RHEL Developer Subscription for small-scale production where official vendor support and a guaranteed lifecycle are required.

Understanding the Relationship Shift

In the previous model, the flow was: RHEL → CentOS Linux. Now, the flow is: CentOS Stream → RHEL → Rebuilds (Rocky/Alma).

• CentOS Stream: A rolling preview. Packages land here first, are tested, and then move into RHEL. It is not a bit-for-bit copy of any current RHEL release.
• RHEL Rebuilds: Projects like Rocky Linux and AlmaLinux aim for bug-for-bug compatibility with RHEL. They take the released RHEL source and rebuild it, maintaining the stable, static nature of a minor release.
• Shared Tooling: Regardless of the choice, dnf remains the package manager. Your skills in managing repositories, modules, and updates transfer across the entire ecosystem.

Practical Decision: Verifying and Migrating

Before migrating, you must identify exactly what you are running. Run these commands as root or with sudo to check your current state:

# Identify the distribution name and version
cat /etc/os-release

# List enabled repositories to see where packages are sourced
sudo dnf repolist

If /etc/os-release indicates CentOS Stream and you require a production-stable rebuild, the safest path is a clean installation of the target OS. While in-place conversion scripts (such as migrate2rocky for Rocky Linux) exist, they carry risks of dependency conflicts, especially if you use third-party repositories or custom kernel modules.

Conceptual Conversion Flow (CentOS Stream to Rocky Linux)

If you choose an in-place conversion on a non-critical system, the general logic follows this sequence:

1. Backup: Create a full system snapshot or VM clone.
2. Preparation: Update all current packages to the latest Stream version.
3. Execution: Download and run the project-specific migration script (e.g., migrate2rocky) which replaces the CentOS Stream release packages with Rocky Linux release packages and synchronizes the repositories.
4. Verification: Reboot and verify the identity via cat /etc/os-release.

Risk: In-place conversions can fail if the system has non-standard package versions or conflicting GPG keys. Always validate the result in a staging environment before applying to production.

Trade-offs and Limitations

Option	Ideal Workload	Primary Advantage	Primary Limitation
CentOS Stream	Dev / CI / Testing	Early visibility of RHEL changes	Rolling nature; not a 1:1 RHEL match
Rocky / Alma	Production Servers	High stability; RHEL compatibility	Lags slightly behind RHEL releases
RHEL (Dev Sub)	Small Production	Official support and lifecycle	Requires account registration

Actionable Closing

To future-proof your infrastructure, follow these three steps:

1. Audit your fleet: Use cat /etc/os-release to find any remaining CentOS Linux 7 or 8 systems and prioritize their migration.
2. Segment by environment: Move your CI/CD runners to CentOS Stream to ensure your code works with the next version of RHEL, but keep your production databases and application servers on a rebuild or RHEL.
3. Validate the migration: If using conversion scripts, test them on a clone. If the system is mission-critical, opt for a clean install to avoid residual configuration drift.