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

subscription-manager works fine for a handful of RHEL hosts. By 300, you need Satellite — not because it's mandatory, but because the alternative is a patchwork of cron jobs, sticky notes, and a Tuesday afternoon outage when half the fleet pulls the same broken update at the same time.

This is the Satellite layout we deploy for customers running RHEL at scale.

The lifecycle environments

Library  →  Dev  →  Staging  →  Production
                                    ↑
                                    Promote here on a 2-week cadence

# Create a content view tied to a specific repo snapshot
hammer content-view create --name "RHEL10-Server" --organization "Customer"
hammer content-view add-repository --name "RHEL10-Server" \
  --repository "Red Hat Enterprise Linux 10 Server"
hammer content-view publish --name "RHEL10-Server" --description "Weekly 2026-05-14"
 
# Promote across lifecycle
hammer content-view version promote --content-view "RHEL10-Server" \
  --version "1.0" --to-lifecycle-environment "Staging"

A content view is a frozen snapshot of repos. Promote across the lifecycle and every host in that environment pulls from exactly the same package set. No surprises.

The full write-up covers:

• Content view composition — base RHEL + EPEL + your internal repos
• Activation keys per environment + per host class
• Hammer CLI vs the Satellite UI — what we automate and what we don't
• Sync plans for upstream Red Hat repos (when to pull, what to pin)
• Errata-driven patching — applying only the security errata, deferring the others
• The air-gapped Satellite sync for customers who can't reach Red Hat directly

We deploy this layout for every managed RHEL fleet over 50 hosts.