Short answer: to patch RHEL servers offline, you need three things. You need a local repository inside the isolated network and a controlled way to bring content across. You also need records that prove what was installed. Red Hat Satellite is one way to do this. Alternatives include self-built reposync mirrors and patch platforms that manage local repositories for you, such as JetPatch.
This guide covers the building blocks of air-gapped RHEL patching, how Satellite handles it, and when a different approach fits.
The three parts of offline RHEL patching
- A local repository. Isolated servers cannot reach the Red Hat CDN. They need a mirror inside the network that dnf or yum can use.
- A path across the gap. New content has to reach that mirror on a regular schedule, through a controlled channel.
- Evidence. Auditors want to know which advisories were applied to which servers, and when.
Whatever tool you choose, you still need valid Red Hat subscriptions for the content. Repository tooling does not replace them.
How Red Hat Satellite handles disconnected networks
Red Hat describes Satellite as an infrastructure management product for keeping RHEL environments running efficiently, securely and in compliance. Red Hat publishes a dedicated guide for installing Satellite in a disconnected network.
That guide describes Inter-Satellite Synchronization (ISS). In the air-gapped scenario, an upstream Satellite connects to the internet and consumes content from the Red Hat CDN. A downstream Satellite is completely isolated. The only way to update it is to export content upstream, carry it across physically and import it.
Red Hat also notes a version rule. For ISS export sync in air-gapped setups, all Satellite Servers must run the same Satellite version.
Satellite is a strong choice for RHEL-centric shops that also want its provisioning and configuration features. The trade-off is infrastructure. The ISS air-gapped model means two Satellite Servers to run and keep in step.
Ways to patch offline RHEL compared
| Approach | Strengths | Trade-offs |
|---|---|---|
| Red Hat Satellite with ISS | Native Red Hat tooling; export and import designed for air gaps | Upstream and downstream servers to run; versions must match for export sync |
| Self-built reposync mirrors | Low software cost; full control | Scripts, certificates and advisory metadata to maintain yourself; one mirror per distribution |
| JetPatch local repositories | One console for RHEL, other Linux, Windows and Unix; advisory-level reporting | A JetPatch Manager to run; Red Hat subscriptions still required |
Many teams start with reposync and createrepo. It works for one distribution. Then the estate grows. Each new distribution or major version adds a mirror server, more scripts and another certificate to manage.
The biggest risk is losing advisory metadata. Without it, you can say a package was updated. You cannot easily prove which RHSA it resolved.
How JetPatch patches isolated RHEL servers
JetPatch manages local Linux repositories as the patch source for servers without internet access. Repositories sync from vendor sources on a cron schedule you control. Servers pull packages from the local mirror only.
The Unified Linux Repository runs every distribution in its own container on one Docker host. An Nginx reverse proxy handles HTTPS termination. Adding a distribution means adding a container, not a server.
JetPatch preserves advisory metadata through the sync. It patches RHEL at the errata level and correlates packages with RHSA, RHBA and RHEA advisories and their CVEs. That gives auditors an advisory-level answer.
The same architecture works at every isolation level. With restricted egress, only the JetPatch Manager may reach vendor sources. In partially isolated networks, the Manager syncs verified content into isolated segments over internal connections. In fully air-gapped setups, the Manager’s vendor connection runs in a scheduled, audited window. Details are on the air-gapped patch management page.
Two features shorten maintenance windows. Pre-download stages packages on each server before the window opens. Transaction-based rollback reverts only the packages from a given cycle on RHEL, Rocky, AlmaLinux, CentOS, SUSE and Amazon Linux. Rollback needs the previous package version in the repository.
Producing compliance evidence
Isolation does not remove the need for proof. A sound offline process records:
- Which advisories each server was missing at the start of the cycle.
- Who approved the patch list and the change window.
- What was installed on each server, and when.
- Which servers failed, and what was done about them.
JetPatch Remediation Plans capture approvals and maintenance windows, and can wait for ServiceNow or Jira change approval. Compliance reports export to CSV and PDF, by OS, environment and plan.
Setting up offline RHEL patching: a checklist
- List every RHEL version and architecture you need to mirror.
- Choose where the connected side sits and who may operate it.
- Define one documented path for content into the isolated zone.
- Set a sync schedule that matches your patch cadence.
- Test patching and rollback on a non-production group first.
Frequently asked questions
Can I patch air-gapped RHEL without Satellite?
Yes. You need a local repository inside the isolated network and a controlled way to refresh it. You can build mirrors yourself or use a platform that manages repositories, such as JetPatch.
Do I still need Red Hat subscriptions?
Yes. Vendor content subscriptions are separate from repository infrastructure. JetPatch removes the work of running mirrors, not the need for subscriptions.
Can I report on RHSA advisories, not just packages?
With JetPatch, yes. It maps installed packages to RHSA, RHBA and RHEA advisories with CVE references. See Linux patch management for details.
Can the same tool patch isolated Windows servers?
Yes. JetPatch Offline Windows Patching delivers verified updates to air-gapped Windows servers. It works with your WSUS or replaces it with the JetPatch repository.
Want to see offline RHEL patching in your own lab? Request an evaluation and test it on an isolated segment.
