Can CentOS Stream 9 be used for servers?

Hello,

i have a question about Centos 9 stream usage.
Can we use Centos 9 stream as a Server.

Best regards

Hello,

Yes, you can use CentOS 9 Stream as a server. Itā€™s a rolling-release version that provides a preview of the next minor release of RHEL, which means itā€™s quite stable and suitable for production environments. Just ensure youā€™re comfortable with its rolling-update model and any associated changes.

Best regards!

A CentOS Stream version will only be active and available until the end of the Full Support Phase of a RHEL Productā€™s Life Cycle. That will generally mean that a CentOS Stream version will become available slightly before the Beta release of that RHEL version and go until 5 years after that version of RHEL officially releases.

That means specifically for CentOS Stream 9, since RHEL 9 released on May 17, 2022 the Full Support Phase would normally stop at the end of the month 5 years later. CentOS Stream 9 would therefore stop development and be archived on May 31, 2027

If you are looking for a longer lifetime than that for your server then RHEL would be more appropriate for that purpose application.

But in general, as Alice Morgan said above, CentOS Stream 9 is a rolling release that previews what will become the next point release of RHEL 9 while it is in development. So, since RHEL 9.4 is the current active release, what is in Stream 9 right now is what is in development to become the RHEL 9.5 release. Once RHEL 9.5 is released, what is in CentOS Stream 9 would transition to become what will be in the RHEL 9.6 release, etc.

1 Like

Iā€™m going to push back against the term ā€œrolling releaseā€. In my experience, it creates too much confusion. When people hear ā€œrolling releaseā€, they think of something that doesnā€™t have major versions and where major changes can land at any time, like Fedora Rawhide or ELN. But thatā€™s not what CentOS Stream is. CentOS Stream has major versions, like Fedora Linux does. But it delivers updates within those major versions continually, rather than batch them into minor versions, again just like Fedora Linux does. Language is hard.

2 Likes

Sure.


If youā€™re coming from Fedora experience, good luck :stuck_out_tongue: I dipped-out of CentOS Stream and RHEL 9 recently after trying to figure out repos for basic apps that I take for-granted just existing on Fedoraā€™s default repos.

Certainly Fedora has a wealth of packages available, while CentOS Stream only has the packages that Red Hat intends to support for 10+ years. But there are a lot of packages in EPEL, which I think most people enable, and itā€™s growing continually. Any package thatā€™s in Fedora and not in CentOS Stream is eligible to be in EPEL, and people can get involved to add more.

Additionally, the CentOS SIGs do a lot of great packaging work in their particular areas, and sometimes there are packages from the SIGs available for the latest CentOS Stream that arenā€™t available for the latest Fedora Linux release. For example, the Cloud SIG packages 7 versions of OpenStack and 4 versions of OKD. With the longer lifecycle of CentOS releases, sometimes you need specific older versions for homogeneous environments.

Anyway, if Fedora meets your needs, thatā€™s awesome. Itā€™s my daily driver. But thereā€™s a lot going on in CentOS besides the core packages in Stream, and a lot of places where people can get involved to help support additional packages. Weā€™re working to better highlight the rest of the ecosystem in the ongoing website revamp efforts.

1 Like

I do think the rolling release is a better explanation of CentOS Stream than anything else. There are regular changes which do not get announced which break various CI/CD regularly without explanation. The one I am walking through some people through is the change of clang-17 to clang-18 recently (as of this writing). Various applications which were compiling fine a day before are now leaving all kinds of tracebacks with some of them looking like the compiler is brokenā€¦ but have turned out that the code itself is using a ā€˜compiler dependent behaviour of C standardā€™ which changedā€¦ [whether clang should give better errors versus tracebacks is someone else.]

Pointing the people to Red Hat Enterprise Linux Application Streams Life Cycle - Red Hat Customer Portal didnā€™t help, but framing it that that CS9 is more of a rolling release and may undergo periods of instability did. It may not be the same rolling release as Arch or Gentoo, but things DO change greatly over the lifetime of a CS release.

Rolling release is a long established term that means no versions, no EOL dates, and no reinstalling. CentOS Stream is 100% not that. The original intent of messaging it as a rolling release was to convey that it rolled from one minor version to the next, but that is better described as just not having minor verisons. It has been quite damaging to the project to have to constantly clarify that CS still follows RHELā€™s major version compatibility rules and isnā€™t full of bleeding edge software like a true rolling release.

While the overall distro is definitely not a rolling release, there are some appstreams that are rolling, including LLVM (which clang is part of). Both CS and RHEL have these rolling appstreams. The difference is that in RHEL the major version bumps for rolling appstreams happens at the OS minor version boundary, which CS doesnā€™t have. Any CI that is blindly tracking the latest RHEL minor version (the most common approach) is going to have the exact same problem, just delayed by a few months. IMO, the flaw here is not that new versions become available, but rather they are maintained as a single unversioned package that updates through the versions. With parallel versioned packages, users can choose the version they want, and stay with it until theyā€™re ready for the next one. This is how Python and Java work, so itā€™s definitely possible. Iā€™m hoping that more appstream take the parallel approach in CS/RHEL 10.

For the clang CI problem, my recommendation would be to do something like dnf install 'clang(major) < 17' to get more consistent results until new major versions of the compiler can be validated. You could also use CI matrix patterns to test against specific major versions (dnf install 'clang(major) = 16', dnf install 'clang(major) = 17', etc.) separately. The caveat to that approach on production systems is that the previous versions are not maintained after the next one comes out, but it should be fine for short lived CI environments.

Just a little further down on that page from the section you linked is the RHEL 9 Rolling Application Streams Release Life Cycle section, which documents which appstreams are rolling. The best way to frame it is that the appstream is rolling, but the OS is not.

Things also change greatly over the lifetime of a RHEL release. RHEL 9 launched with clang 13, and has upgraded through 14, 15, 16, and now 17. The clang 18 update youā€™re seeing in CS now is expected to land with RHEL 9.5. This is just the nature of rolling appstreams, and isnā€™t a problem exclusive to CS.

3 Likes