Updating Linux is a solved problem. Right up until you have a hundred servers.
Update everything, all the time
If you run Linux on your own machine, updates are easy. Whether it's apt in the Debian family or pacman on Arch, the loop is the same. Run the update and get what's new, often within days of it shipping upstream.
It's the same model your laptop runs on. The vendor pushes, you get it. For one person on one machine, it's great. If something breaks, you're the only one who notices... and you're the one who fixes it.
But fast has a cost. In July 2025, three packages in the Arch User Repository, the community-run corner of Arch, posed as patched browser builds and installed a remote access trojan. The community caught them and they were gone in about two days. Two days is a quick response for a hobbyist desktop. It's a very long time if those packages landed on production servers.
That's the trade enterprises make when they pick Enterprise Linux. Less new, much less risk.
The legacy Enterprise Linux playbook
Legacy Enterprise Linux vendors have traditionally gone the other way. They update less often, on purpose. Someone at the vendor spends a lot of time deciding which RPM package versions go into each release, and which ones sit out because they're unproven or might not play nice with the rest of the system.
That curation is a big part of what the subscription pays for, and the vendor's repository becomes the pillar everything gets built around. Fair enough. Stability is the whole point, and it's the same reason Rocky Linux from CIQ exists.
But the way the legacy vendors deliver that stability hasn't changed much in a long time, and at fleet scale it starts to creak.
Where it starts to creak
- The vendor curates for everyone, which means nobody curated for you. Their testing, their priorities, their calendar. Who do you actually want deciding what lands on your production servers?
- Every host goes and asks for itself. A hundred servers means a hundred machines checking the same off-site list, over and over. A caching proxy cuts the traffic, but it doesn't decide anything.
- Staging is on you. Want dev to update first, get tested, and then let production follow on its own schedule? That's manual work, and you redo it every cycle.
- Your own packages become orphans. Most shops have a few custom RPMs. They live outside the curated repository, so someone babysits their installs and updates by hand.
A layer between the repository and the fleet
That's why we built CIQ Enterprise Linux Manager (ELM). It sits between where packages come from and the hosts that install them, and it gives the decision back to your team.
It starts with a source of truth you own. ELM mirrors upstream repositories onto your storage, and hosts pull from you and not constantly over the internet. That runs on infrastructure you already operate, connected or not.
Then you decide what each host installs. A content view is a named, versioned snapshot of exactly what a group of hosts should get. One view can combine upstream Enterprise Linux content, RLC Pro content from CIQ, and your own custom RPMs. The internal packages get managed like everything else instead of on the side. And nothing gets built until you hit compose.
Then you split the fleet. Dev tracks the latest snapshot. Production is pinned to one you've tested and doesn't move until someone moves it. Promoting is re-pointing production at a newer snapshot. Rolling back is re-pointing it at an older one. Every compose is kept, so you have a history of what ran where. (For more info, I wrote about that in The CVE didn't bring the fleet down.)
Say you need to pull a package out of the fleet. You exclude it from the dev content view and recompose. Your dev hosts stop seeing it. Your production hosts still have it, because production is pinned to the snapshot you already tested. Same fleet, two different answers, and both are the ones you chose. Once dev checks out, you promote, and production follows.
None of that asks you to give up what you picked Enterprise Linux for in the first place. You still get a stable, curated core. What changes is who decides when it reaches each host. The mirror lives on your storage, your custom packages sit right alongside everyone else's, and production moves when your team moves it.
And it's not another tool to buy and budget for. CIQ provides ELM at no additional charge to all RLC Pro subscriptions.
Production should change when you decide
It should be dictated when a package changes and also not on the vendor's calendar.
For the bigger picture, read Own your Enterprise Linux lifecycle, or head to the CIQ Enterprise Linux Manager page for the details.
