Managing RHEL at scale — Satellite, content views and the lifecycle we actually ship

Every RHEL shop we've onboarded follows the same arc. Start with 5 hosts and subscription-manager register. Grow to 30 hosts and a dnf update cron job. Grow to 100 hosts and a panicked email from compliance asking "which servers are running the patched OpenSSL?" Nobody knows.

We run managed RHEL for customers with fleets ranging from a dozen hosts up to several thousand. The line where ad-hoc subscription management stops working is somewhere around 50 hosts, and the answer past that line is almost always Red Hat Satellite (or its upstream, Foreman + Katello, for customers who want to stay non-Red-Hat-paid).

This post is the Satellite layout we actually deploy, the content view discipline that keeps it useful, and the mistakes we've made so you can skip them.

Why subscription-manager alone fails past 50 hosts

subscription-manager is fine for a handful of hosts. The problems start showing up at scale:

• No staging. Every host pulls from the same Red Hat CDN. If RHEL ships a kernel update at 3am, every host with dnf-automatic enabled installs it at 3am. We've watched a regression in a kernel update take out half a customer's prod fleet in 90 minutes.
• No point-in-time content. You cannot say "promote exactly the package set we tested in staging to prod." The CDN is a moving target.
• No air-gapped option. Many of our customers run RHEL in environments without direct internet egress (PCI, government, regulated finance). They need a local mirror.
• No useful inventory. subscription-manager list --consumed will tell you which subscriptions are attached, but it won't tell you which hosts are 90 days behind on patches.

Satellite addresses all four. It is also genuinely heavy software — the deployment is two days, not two hours — and that's the trade-off.

The Satellite layout we deploy

For fleets above 100 hosts we deploy a Satellite 6.15 server (RHEL 9 host, 8 vCPU, 32 GB RAM, 500 GB storage for content) plus Capsule servers in any region or network segment that can't reach the Satellite directly.

[Satellite Server] - Sydney
        |
        |--- [Capsule] - Melbourne DC
        |--- [Capsule] - AWS ap-southeast-2 VPC
        |--- [Capsule] - Azure australiaeast (isolated subnet)
        |
   [RHEL 8/9/10 content from Red Hat CDN]

Each Capsule mirrors the content the Satellite has, and clients in that segment register against the Capsule, not the Satellite. This matters for two reasons: bandwidth (a 4 GB kernel update pulled once to the Capsule, then served locally to 200 hosts), and reachability (the Capsule in a private VPC has a route to its clients; the Satellite in our management network does not).

Content views: where the discipline lives

A content view in Satellite is a snapshot of one or more repositories at a point in time. The discipline that makes this useful is treating content views as immutable, versioned, promoted. Same model as a Docker image, applied to RPM content.

Our standard layout:

Content View: RHEL9-Base
  - Repository: Red Hat Enterprise Linux 9 for x86_64 - BaseOS RPMs
  - Repository: Red Hat Enterprise Linux 9 for x86_64 - AppStream RPMs
  - Repository: Red Hat Satellite Client 6 for RHEL 9 x86_64 RPMs
  - Filter: include errata up to <date>

Once a month, on the second Tuesday (one day after Red Hat's patch Tuesday), we publish a new version of this content view. That action snapshots whatever the upstream repos contain at that moment. Version 47 will always contain the same RPMs, regardless of what Red Hat does next.

Lifecycle environments: the promotion path

Lifecycle environments are the staging path that content views move through. Our default:

Library --> Dev --> Test --> Staging --> Prod

A new content view version is published into Library. We then promote it to Dev. Hosts registered to Dev pick up the new content. They run for 48 hours. If nothing breaks, we promote to Test. Test runs for another 5 days. Then Staging. Then Prod.

This means a CVE patch lands in Prod roughly 10 days after Red Hat ships it. That delay is the conscious cost of stability. For critical CVEs (CVSS 9+, or active exploitation), we have a fast-track lane that bypasses the wait — published, promoted to Test, and pushed to Prod inside 24 hours, with explicit signoff from the customer's security lead.

# Publish a new version of the content view
hammer content-view publish \
  --organization "ACME" \
  --name "RHEL9-Base" \
  --description "May 2026 patch cycle"
 
# Promote that version to Dev
hammer content-view version promote \
  --organization "ACME" \
  --content-view "RHEL9-Base" \
  --version "48.0" \
  --to-lifecycle-environment "Dev"

All of this lives in version-controlled scripts. The hammer CLI is excellent and we use it from CI rather than the Satellite UI. The UI is for browsing, the CLI is for changes.

Activation keys: how clients pick the right content

An activation key is a named bundle of "register this host, attach this subscription, point at this content view, place it in this lifecycle environment." We define one per (lifecycle environment, host role) pair:

ak-rhel9-prod-web
ak-rhel9-prod-db
ak-rhel9-staging-web
ak-rhel9-dev-web

When we provision a new RHEL host via Kickstart or cloud-init, the activation key is the one parameter that determines everything else:

subscription-manager register \
  --org="ACME" \
  --activationkey="ak-rhel9-prod-web"

That one command attaches the right subscription, enables the right repositories, sets the right release version, and joins the right host group. The host now knows what it is, and Satellite now knows about the host.

Host collections and remote execution

Once hosts are registered, you can group them. We use host collections for the obvious axes (web, db, jump-host) and for ad-hoc grouping during incidents ("the 14 hosts in the broken AZ"). Host collections drive bulk operations:

hammer host-collection update-packages \
  --organization "ACME" \
  --name "prod-web" \
  --packages "openssl,openssl-libs"

This pushes the update to all members in parallel, returns a job ID, and you can watch progress in real time. For an emergency CVE patch across 200 web hosts, this is a 5-minute operation rather than a 5-hour one. We document the procedure in the runbook so the on-call engineer doesn't have to think about it at 3am.

Errata management: the auditable bit

Satellite tracks errata (Red Hat's CVE and bug-fix advisories) per host. The dashboard answers compliance's question directly: "show me every host missing security errata older than 30 days." We export this monthly and ship it to customers as a patch compliance report.

The query that produces it:

hammer host errata list \
  --organization "ACME" \
  --search "type = security and installed = false" \
  --per-page 1000

For managed customers, the patch compliance report is part of the monthly service deliverable. The signal it carries — "every host we run is currently inside the patch SLA, here is the evidence" — is the thing that makes RHEL feel different from a haphazard Ubuntu fleet in 2026.

Air-gapped deployments

For our regulated finance and government customers, the Satellite has no internet egress. Content arrives via inter-satellite sync from a sister Satellite that does, or via satellite-sync from an export tarball. We've used both. The export model is fiddler (you're shipping 40 GB tarballs around) but appropriate when policy says no outbound connections from the secure zone.

# On the connected Satellite — export
hammer content-export complete library \
  --organization "ACME"
 
# On the air-gapped Satellite — import
hammer content-import library \
  --organization "ACME" \
  --path /imports/export-2026-05-14

What we don't recommend

Some patterns we've seen and chosen not to use:

• Skipping lifecycle environments and pushing straight from Library to Prod. This is what people do when they're tired of waiting for Satellite to publish content view versions. It defeats the entire point of Satellite. If the wait is the problem, the answer is to publish more often, not to skip stages.
• Using composite content views for everything. Composite views (a content view of content views) are powerful but the dependency tracking becomes a nightmare. We use them only when we genuinely need to layer org-wide policy content on top of base RHEL.
• dnf-automatic on production hosts. Yes, even with Satellite. The promotion model gives you controlled rollouts. Automatic update on the host defeats it.
• One content view per host role. Tempting, but multiplies the number of things you have to maintain. Start with one base content view and overlay role-specific bits through Ansible.

How this compares to the alternatives

For customers running mixed fleets, we get asked how this compares to managed Ubuntu at scale. The honest answer: Canonical Landscape covers the same ground for Ubuntu, with a slightly different model (less content view discipline, more focus on snap channels and Livepatch). Satellite is more mature, has been doing this since 2014, and ties into the Red Hat ecosystem (Insights, ACM, OpenShift) in ways Landscape doesn't.

Where Satellite genuinely struggles is the first install. Standing up a Satellite from scratch is a real project — plan two days, document the storage choices, get the right certificates in place from the start. We do this often enough that we have an opinionated playbook; if you're doing it for the first time, expect a learning curve.

The summary

If your RHEL fleet is bigger than a handful of hosts and you don't have Satellite (or Landscape, or some equivalent), patch management is currently happening by tribal knowledge and luck. Satellite isn't fun software — it's heavy, it has its own opinions, and the first week of using it is genuinely tedious. But it's the difference between "we run 300 RHEL hosts and we know exactly what's on them" and "we run 300 RHEL hosts and we hope."

If you'd like a hand standing one up — or auditing what you already have — that's a conversation we have weekly. Reach out and we'll scope it.

Sudhanshu K. is a Principal SRE at EdgeServers (RemotIQ Pty Ltd, ABN 91 682 628 128). He has been running RHEL in production since RHEL 4 and has the scars from migrating off RHN Classic to remember why Satellite is worth the effort.