We offer release packages containing our repository configuration files and public package signing keys. Use the version that corresponds to the major version of your operating system.

For convenience some distributions include these release packages in their default repositories, allowing you to install them by name without the full URL.

Some EPEL packages depend on packages from repositories that are not enabled by default. Take note of the additional repositories being enabled in the following instructions.

CentOS Stream 9

dnf config-manager --set-enabled crb
dnf install epel-release epel-next-release

subscription-manager repos --enable rhel-*-optional-rpms \
                           --enable rhel-*-extras-rpms \
                           --enable rhel-ha-for-rhel-*-server-rpms
yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special Interest Group that creates, maintains, and manages a high quality set of additional packages for Enterprise Linux, including, but not limited to, Red Hat Enterprise Linux (RHEL), CentOS, Scientific Linux (SL), Oracle Linux (OL), AlmaLinux (AL) and Rocky Linux (RL).

EPEL packages are usually based on their Fedora counterparts and should not conflict with or replace packages in the base Enterprise Linux distributions. EPEL uses much of the same infrastructure as Fedora, including buildsystem, Bugzilla instance, updates manager, mirror manager and more.

Learn more about EPEL in the following pages:

EPEL packages are built against RHEL. EPEL Next packages are built against CentOS Stream.

EPEL-Next is not a complete rebuild of all the EPEL packages, but only those packages that need to be rebuilt to install on CentOS Stream. The EPEL-Next repo is meant to be layered on top of the regular EPEL repository.

Learn more about EPEL-Next on the following page:

Since EPEL is part of the Fedora project, you can search the available packages in the Fedora Packages web app . This provides an overview of available versions across various EPEL branches. If you find a package that is not yet available in the EPEL branch you would like it to be, please follow this guide to request it.

Alternately, you can browse the repo files directly:

EPEL has an 'epel-release' package that includes GPG keys for package signing and repository information. Installing this package for your Enterprise Linux version should allow you to use normal tools such as yum to install packages and their dependencies. By default the stable EPEL repo is enabled, there is also a 'epel-testing' repository that contains packages that are not yet deemed stable.

NOTE for RHN users: You need to also enable the 'optional ' repository to use EPEL packages as they depend on packages in that repository. This can be done by enabling the RHEL optional subchannel for RHN-Classic. For certificate-based subscriptions see Hat Subscription Management Guide.

NOTE for RHEL 7 users with certificate subscriptions: EPEL 7 packages assume that the 'optional ' repository (rhel-7-server-optional-rpms for servers) and the 'extras ' repository (rhel-7-server-extras-rpms for servers) are enabled. You can do this with:

NOTE for RHEL 8 users with certificate subscriptions: EPEL packages assume that the 'codeready-builder ' repository is enabled. You can do this with:

NOTE for CentOS users: You can install EPEL by running yum install epel-release . The package is included in the CentOS Extras repository, enabled by default.

The EPEL project strives to provide packages with both high quality and stability. However, EPEL is maintained by a community of people who generally volunteer their time and no commercial support is provided. It is the nature of such a project that packages will come and go from the EPEL repositories over the course of a single release. In addition, it is possible that occasionally an incompatible update will be released such that administrator action is required. By policy these are announced in advance in order to give administrators time to test and provide suggestions.

It is strongly recommended that if you make use of EPEL, and especially if you rely upon it, that you subscribe to the epel-announce list. Traffic on this list is kept to a minimum needed to notify administrators of important updates.

The EPEL project was born when Fedora maintainers realized that the same infrastructure that builds and maintains packages for Fedora would be great to also maintain add on packages for Enterprise Linux. Much of the early need was driven by what Fedora infrastructure needed on the RHEL machines that built and maintained Fedora. From there things have grown to a large collection of varied packages. See our history and Philosophy page for more information.

EPEL is always looking for interested folks to help out. We always need package maintainers, QA/testers, bug triagers and documentation writers. Please see our Joining EPEL page for more information on how to join EPEL.

The #epel IRC channel on Libera Chat offers real-time support for EPEL users and developers. This channel is bridged to epel:fedoraproject.org on Matrix.

The epel-devel mailing list is for general EPEL discussion. Historic archives are available.

If you find a bug in a EPEL maintained package, please report it to https://bugzilla.redhat.com/ under the "Fedora EPEL" product.

Infrastructure issues (mirrors, repos, etc.) should be reported to Fedora releng .

The EPEL Steering Committee meets on Wednesday every week in the Fedora Meeting 1 Matrix channel. The time is not tied to U.S. daylight savings time, so it is at 18:00 UTC regardless of the time of year. Please check the time on the epel calendar ; sometimes it can change or a meeting can be skipped. Feel free to join us! Logs of past meetings can be viewed in meetbot .

The EPEL Steering Committee has monthly office hours for the EPEL project .