On CIQ Enterprise Linux Manager (ELM), you resolve entitlement once, at your mirror. Your subscription authenticates against CIQ Depot at sync time, and every host afterward installs from that mirror. That is true at 200 hosts and at 20,000, because entitlement resolves upstream of your fleet.
Every content view you build inherits entitlement from one Depot sync, and so does every host that installs from the view.
Give entitlement one place to resolve
Depot, the CIQ service your RLC Pro subscription authenticates against, governs which repositories you can mirror. You point ELM at Depot with your credentials, sync those repositories onto your own mirror, and curate content views out of them. Your host groups install from a published view.
Enterprise Linux entitlement covers the Depot share of that mirror. Your own internal repositories and open repositories such as Extra Packages for Enterprise Linux (EPEL) sync on the same schedule, and a content view draws from all three sources as one catalog. Mirroring accepts any RPM-based distribution, while curation, dependency resolution, and errata target Enterprise Linux content only.
What does a host check before it installs a package from a content view? Its repository configuration. That configuration reaches the host through the optional lightweight ELM agent or through a repository file you hand out with Ansible. Either way, the host resolves the content view version its host group points at, then installs through standard package management. See what ELM covers, from mirror through rollback.
Take the subscription-enforcement service out of the runbook
An entitlement model that reaches the host creates operational work, and that work scales with the fleet. Your operations team stands the service up, keeps it reachable from every segment that installs packages, registers each host against it, and reconciles that record as machines join, move between groups, and retire. Teams run this model successfully at every fleet size. That work lands in the runbook, and it stays there for the life of the fleet.
ELM asks for a mirror, the storage under it, a sync schedule, and the curation work that moves each view into production. None of that scales with host count. Point another 5,000 machines at a content view, and you change the host count while the entitlement path stays where it was.
What happens to a rollout if Depot is unreachable? It finishes. The content the rollout needs already sits on your mirror, and the ELM control plane makes no license callback and sends no telemetry. An interruption at Depot delays your next mirror refresh, and the promotion you scheduled for Friday still runs.
ELM governs its users on a separate track, with its own accounts and role-based access control, wired to a directory over LDAP or SAML. You decide who can curate a view, who can promote one into production, and who can only read what shipped.
Entitlement decides which content your subscription covers. Role-based access control decides who on your team moves it.
See entitlement resolve at the mirror Request a demo: ELM syncs entitled content, curates a view, and promotes it into production
Keep entitlement out of the install path
Four decisions determine what a host runs, and each resolves in a different place.
The first two decisions are separate, but an enforcement model binds them together by design, which is why it needs a service in the middle. Keep them apart, and your rollout path runs on repository configuration alone.
Disconnected segments resolve entitlement before the content ever leaves a connected system. Lifecycle control that runs on-premises covers that boundary in full.
Evaluating ELM for your own fleet? Request a demo of a content view curated, promoted, and rolled back