How to Install EPEL on CentOS Stream 10 and 9

Installing EPEL on CentOS Stream expands package availability beyond BaseOS and AppStream, but the repository set differs by release. Stream 10 uses standard EPEL, while Fedora’s current Stream 9 instructions add standard EPEL and EPEL Next together. The version-matched workflow below enables CRB and verifies signing trust and working repository access.

EPEL adds packages that are not shipped in CentOS Stream BaseOS or AppStream, including htop, Lynis, Fail2Ban, and many server utilities. It complements the CentOS Stream repositories rather than replacing their core packages.

Install EPEL on CentOS Stream 10 or 9

Check the installed CentOS Stream release so you can select the correct EPEL package:

cat /etc/centos-release

Commands that change packages or repository state use sudo, while read-only checks run without it. If your account cannot use sudo, first create a sudo user on CentOS Stream; otherwise enter your account password when prompted.

Update CentOS Stream

Refresh package metadata and apply available updates before adding EPEL:

sudo dnf upgrade --refresh

Check and Enable CRB

CRB provides development libraries and dependencies used by many EPEL packages. Check whether it is already enabled:

dnf repolist --enabled | grep -E '^crb[[:space:]]'

If the command displays the CRB repository, continue to the EPEL installation. If it produces no output, check whether config-manager is available:

dnf config-manager --help

Install the plugin package only if DNF reports that config-manager is unavailable:

sudo dnf install dnf-plugins-core

Enable CRB, then verify the resulting state. The enable command can finish without output, including when CRB is already enabled, so use the repository list as proof:

sudo dnf config-manager --set-enabled crb
dnf repolist --enabled | grep -E '^crb[[:space:]]'

Expected output identifies the matching Stream release:

CentOS Stream 10:

crb                           CentOS Stream 10 - CRB

CentOS Stream 9:

crb                           CentOS Stream 9 - CRB

Review the EPEL Signing Key

The EPEL release package places its signing-key file under /etc/pki/rpm-gpg/. DNF normally asks to import that key into RPM’s key database during the first transaction that installs a signed EPEL package, such as the later htop example. Compare the displayed fingerprint with Fedora’s official signing-key list before accepting it:

EPEL 10
Key ID     : 0xE37ED158
User ID    : Fedora (epel10) <epel@fedoraproject.org>
Fingerprint: 7D8D 15CB FC4E 6268 8591 FB26 33D9 8517 E37E D158
Key file   : /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-10

EPEL 9
Key ID     : 0x3228467C
User ID    : Fedora (epel9) <epel@fedoraproject.org>
Fingerprint: FF8A D134 4597 106E CE81 3B91 8A38 72BF 3228 467C
Key file   : /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-9

Install the EPEL Release Package

Use Fedora’s official permalink for your CentOS Stream major version. Review the DNF transaction before confirming it.

CentOS Stream 10:

sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-10.noarch.rpm

CentOS Stream 9:

sudo dnf install https://dl.fedoraproject.org/pub/epel/epel{,-next}-release-latest-9.noarch.rpm

Bash expands {,-next} so the Stream 9 command installs both epel-release and epel-next-release, matching Fedora’s current CentOS Stream 9 instructions. EPEL Next is not published for CentOS Stream 10.

Installing the release package creates and enables the EPEL repository definitions; do not run a separate dnf enable epel command. The shorter sudo dnf install epel-release command can work when extras-common supplies a copy, but that copy can lag behind Fedora’s current release package and its weak-dependency behavior can differ. The upstream permalinks keep this workflow aligned with Fedora’s documented installation path.

Verify EPEL Repository Access

On CentOS Stream 10, confirm the standard EPEL release package:

rpm -q epel-release

On CentOS Stream 9, confirm both release packages:

rpm -q epel-release epel-next-release

Refresh repository metadata, then check the enabled EPEL IDs. A successful refresh proves that DNF can read the configured sources:

sudo dnf makecache --refresh
dnf repolist --enabled | grep -E '^epel([[:space:]]|-next[[:space:]])'

Example x86_64 output on CentOS Stream 10 contains standard EPEL:

epel                   Extra Packages for Enterprise Linux 10 - x86_64

Example x86_64 output on CentOS Stream 9 contains standard EPEL and EPEL Next:

epel                Extra Packages for Enterprise Linux 9 - x86_64
epel-next           Extra Packages for Enterprise Linux 9 - Next - x86_64

Inspect stable repository fields for standard EPEL:

dnf repoinfo epel | grep -E '^(Repo-id|Repo-name|Repo-status|Repo-filename)'

The result should identify epel as enabled and show /etc/yum.repos.d/epel.repo as its configuration file. If the package is installed but no repository appears, use the Restore Missing EPEL Repository or Key Files troubleshooting branch instead of repeating the normal install command.

Detailed EPEL 10 metadata may contain a minor-version component in its mirror path. Continue using the stable epel repository ID; the release package manages the current compatible path.

Understand EPEL and EPEL Next

EPEL 10’s leading minor repository is built against CentOS Stream 10. Standard EPEL 9 is built against RHEL 9, while EPEL Next provides companion builds against CentOS Stream 9 when a package needs newer Stream dependencies. Fedora’s current Stream 9 setup installs both release packages so these repositories can coexist.

Repository	Install On	Built Against	Purpose
EPEL 10	CentOS Stream 10	CentOS Stream 10 for the leading minor; matching RHEL releases for trailing minors	Main extra-package repository
EPEL 9	CentOS Stream 9	RHEL 9	Main extra-package repository
EPEL Next 9	CentOS Stream 9	CentOS Stream 9	Companion builds for Stream-specific dependencies

Find and Install Packages from EPEL

After EPEL is enabled, DNF can search and install packages from it like any other enabled repository. Examples available from EPEL on both supported CentOS Stream releases include htop, lynis, and fail2ban.

Check package availability:

dnf list --available htop lynis fail2ban

The result identifies each package’s current version, architecture, and source repository. Versions change as EPEL publishes updates, so use the live DNF result and confirm that the repository column is epel.

Search for package descriptions when you do not know the exact package name:

dnf search htop

Install htop, then verify and launch it:

sudo dnf install htop
htop --version
htop

Press q to exit htop, then confirm which repository supplied the installed package:

dnf info htop | grep -E '^(Name|Repository|From repo|Summary)'

Name         : htop
Repository   : @System
From repo    : epel
Summary      : Interactive process viewer

The From repo: epel line confirms the package came from EPEL.

For a larger EPEL-backed workflow, see how to install XFCE on CentOS Stream 9, whose desktop packages require EPEL.

Update EPEL Packages

EPEL participates in normal DNF updates after its repositories are enabled. This command updates CentOS Stream packages, EPEL applications, and the EPEL release packages when updates are available:

sudo dnf upgrade --refresh

You do not need to download the release RPM again for routine updates.

Remove EPEL from CentOS Stream

Identify packages installed from EPEL or EPEL Next before removing their source. Any package you retain remains installed, but it will no longer receive updates from EPEL after its repository is removed:

dnf list --installed | grep -E '@epel(-next)?([[:space:]]|$)'

Remove only the applications you no longer want. For example, remove the package installed earlier:

sudo dnf remove htop

On CentOS Stream 10, remove the standard EPEL release package:

sudo dnf remove epel-release

On CentOS Stream 9, remove the standard and Next release packages in the same reviewed transaction:

sudo dnf remove epel-next-release epel-release

epel-next-release depends on the matching standard release package. Removing standard EPEL while Next remains installed can therefore make DNF propose removing both; removing only Next leaves standard EPEL available.

On Stream 10, verify that the standard release package is absent:

rpm -q epel-release

On Stream 9, verify that both release packages are absent:

rpm -q epel-release epel-next-release

Then check all repository states and the package-owned repository, saved configuration, and key files:

dnf repolist --all | grep -E '^epel'
find /etc/yum.repos.d -maxdepth 1 -type f -name 'epel*.repo*' -print
find /etc/pki/rpm-gpg -maxdepth 1 -type f -name 'RPM-GPG-KEY-EPEL-*' -print

RPM should report the release package or packages as not installed, and the repository and find checks should produce no output after an unmodified setup. Removing a release package deletes its unchanged package-owned repository definitions and key file. If an edited configuration leaves an exact .repo.rpmsave or .repo.rpmnew file, inspect it and remove it only when you no longer need its settings. RPM can also retain a previously imported public-key record; remove that record only as deliberate full-trust cleanup after identifying the exact key and proving that no retained EPEL repository or package needs it. Never erase keys with a broad wildcard.

Keep CRB enabled unless you confirmed that you enabled it only for EPEL and no retained software needs it. To restore a previously disabled CRB state after that check, disable it and confirm the resulting row reports disabled:

sudo dnf config-manager --set-disabled crb
dnf repolist --all | grep -E '^crb[[:space:]]'

Clear cached EPEL metadata and rebuild metadata for the repositories that remain enabled:

sudo dnf clean metadata
sudo dnf makecache --refresh

Finally, preview unused dependency cleanup without accepting the transaction:

sudo dnf autoremove --assumeno

Review every proposed removal. Rerun the command without --assumeno only when every package in the transaction is intentionally disposable; otherwise leave those dependencies installed.

Troubleshoot EPEL Installation

Fix config-manager: Command Not Found

Minimal CentOS Stream installations may not include the DNF plugin command used to enable CRB. Install its provider, retry the enable command, and verify the repository state:

sudo dnf install dnf-plugins-core
sudo dnf config-manager --set-enabled crb
dnf repolist --enabled | grep -E '^crb[[:space:]]'

Fix CRB Not Appearing as Enabled

dnf config-manager --set-enabled crb can complete silently, whether it changed the state or CRB was already enabled. Do not wait for an already active message. Rerun the whitespace-aware repository check above; if it remains empty, inspect all CRB states:

dnf repolist --all | grep -E '^crb[[:space:]]'

If CRB is listed as disabled, rerun the enable command and check again. If no CRB row exists, confirm that BaseOS, AppStream, and extras-common are enabled before changing repository files.

Restore Missing EPEL Repository or Key Files

If rpm -q epel-release succeeds but no EPEL repository appears, or a package-owned EPEL key file is missing, verify the installed release-package files. RPM prints nothing when every tracked file matches; a line beginning with missing identifies a lost file.

CentOS Stream 10:

rpm -V epel-release

CentOS Stream 9:

rpm -V epel-release epel-next-release

If verification reports a missing repository or key file, deliberately reinstall the version-matched release package. A normal dnf install can be a successful no-op when the package is already installed, leaving the deleted file unrestored.

CentOS Stream 10:

sudo dnf reinstall https://dl.fedoraproject.org/pub/epel/epel-release-latest-10.noarch.rpm

CentOS Stream 9:

sudo dnf reinstall https://dl.fedoraproject.org/pub/epel/epel{,-next}-release-latest-9.noarch.rpm

Repeat the applicable rpm -V command; no output confirms that the tracked files were restored. Then refresh metadata and confirm repository access:

sudo dnf makecache --refresh
dnf repolist --enabled | grep -E '^epel([[:space:]]|-next[[:space:]])'

Fix Unable to Find a Match: epel-release

If sudo dnf install epel-release returns Error: Unable to find a match: epel-release, DNF did not find the CentOS-carried shortcut package in its enabled repositories. Confirm that extras-common is enabled:

dnf repolist --enabled | grep -E '^extras-common[[:space:]]'

Do not add an unofficial source. Install the release package directly from Fedora’s version-specific permalink, which does not depend on the CentOS-carried shortcut.

CentOS Stream 10:

sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-10.noarch.rpm

CentOS Stream 9:

sudo dnf install https://dl.fedoraproject.org/pub/epel/epel{,-next}-release-latest-9.noarch.rpm

Older instructions may use yum install epel-release; CentOS Stream 10 and 9 use DNF4 for this workflow. Refresh metadata and confirm the expected repository IDs after the direct install:

sudo dnf makecache --refresh
dnf repolist --enabled | grep -E '^epel([[:space:]]|-next[[:space:]])'

Fix EPEL Public Key Errors

If DNF reports that a public key is not installed while installing a package from EPEL, do not disable GPG checking. Compare any import prompt with the Fedora fingerprint shown earlier, then confirm that the standard release package is installed and its tracked key file is intact:

rpm -q epel-release
rpm -V epel-release
find /etc/pki/rpm-gpg -maxdepth 1 -type f -name 'RPM-GPG-KEY-EPEL-*' -print

If rpm -q reports that epel-release is absent, install the applicable Fedora release package from the preceding branch. If rpm -V reports a missing or changed key file, use the reinstall procedure in Restore Missing EPEL Repository or Key Files. When the package and file are intact but the import prompt does not resolve the error, import that exact package-owned key after confirming its key ID and official fingerprint.

CentOS Stream 10:

sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-10
rpm -qa 'gpg-pubkey*' | grep -F 'e37ed158'

CentOS Stream 9:

sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-9
rpm -qa 'gpg-pubkey*' | grep -F '3228467c'

The query should return the matching gpg-pubkey record. Retry the exact signed-package transaction that failed; when following this guide, that transaction is sudo dnf install htop.

Fix EPEL Mirror and Metadata Errors

If dnf fails to reach EPEL mirrors, it may show an error similar to:

Error: Failed to download metadata for repo 'epel':
Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried

Refresh only repository metadata first:

sudo dnf clean metadata
sudo dnf makecache --refresh

If every mirror still fails, wait and retry before changing repository files. A transient outage does not justify pinning a base URL that can become stale.

Resolve EPEL Dependency Conflicts

EPEL complements CentOS Stream without intentionally replacing its core packages. Dependency errors can come from a disabled base repository, a missing build for the release or architecture, package exclusions, version lag, or an incompatible third-party build.

If DNF reports conflicting requests or nothing provides during an EPEL transaction, start with the enabled repository list:

dnf repolist --enabled | grep -E '^(baseos|appstream|crb|epel)([[:space:]]|-next[[:space:]])'

Then inspect what the failing package requires:

dnf repoquery --requires --resolve htop

Replace htop with the exact package that failed. If you disabled BaseOS, AppStream, or CRB for a transaction, re-enable it and retry. EPEL Next can supplement standard EPEL only on Stream 9; it is not an alternative source for a missing Stream 10 package.

If DNF identifies a third-party version conflict, inspect the installed package’s source and the full proposed transaction before changing it. Remove or replace a conflicting build only when you understand which dependent packages the transaction will affect.

Archived EPEL Releases

The Fedora Project archives older EPEL releases after they leave maintenance, and those repositories no longer receive updates. The EPEL archive can help with legacy recovery, but production systems should move to a supported CentOS Stream or Enterprise Linux release.

Conclusion

EPEL is ready when metadata refresh and an EPEL package query succeed. CentOS Stream 10 should show epel; CentOS Stream 9 should show both epel and epel-next. Keep epel-release (and epel-next-release on Stream 9) installed while EPEL applications need updates; before removing repository access, identify and remove or intentionally retain EPEL-sourced packages. Fedora’s official EPEL documentation remains the upstream reference for future setup changes.