Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
Install NGINX on CentOS 8 from the official NGINX yum/dnf repository. The stable channel is enabled by default; mainline is an opt-in alternative. Create the repository file, refresh metadata, verify the NGINX signing key fingerprint before importing it, install the package, then start NGINX and test 127.0.0.1 with curl.
What this procedure installs
This guide installs the open-source NGINX package on a CentOS 8 machine using the repository method documented for RHEL-based systems. The same installation family covers RHEL, CentOS, Oracle Linux, AlmaLinux and Rocky Linux. You will use dnf, the normal CentOS 8 successor to yum, while the repository itself is hosted by NGINX.
The repository configuration contains two channels:
| Channel | Repository state in the supplied configuration | When it fits |
|---|---|---|
| Stable | Enabled (enabled=1) |
Choose this conservative default for most production systems and when you want the channel published as the standard installation path. |
| Mainline | Disabled (enabled=0) |
Enable it deliberately when you need newer NGINX releases and have tested application and module compatibility. |
Stable and mainline are separate repository channels, not two commands that install different software simultaneously. Select one channel before installing or updating packages, and test the choice with your own application and module set.
Prerequisites before you begin
- A server running CentOS 8. Confirm the operating system and release before creating a repository that uses the
$releasevervariable. - An account with
sudoprivileges. - Network access to the NGINX package repository and its signing-key URL.
- A decision about stable versus mainline. If you have no specific reason to use mainline, leave stable enabled.
The commands below install the open-source package. They do not install NGINX Plus, which is a separately licensed product requiring its own repository and credentials.
Choose stable or mainline
Stable: the default path
The official repository marks stable as enabled by default. It is the least surprising choice when operational conservatism, established module behavior and compatibility with an existing application matter more than receiving the newest release as soon as it is published.
Mainline: an intentional opt-in
Mainline is provided in a second repository section and is disabled initially. It can provide newer NGINX releases, but the installation guide does not promise identical module or compatibility behavior for every deployment. Enable it only after testing your application, configuration and any dynamic modules against the versions you intend to run.
Do not enable both channels for routine operation. Keep one channel selected so package updates have a clear source and so you can explain which release stream was used when troubleshooting.
Step 1: Create the official NGINX repository file
Create /etc/yum.repos.d/nginx.repo with root privileges. The following layout is the repository configuration published for CentOS and includes both channels:
[nginx-stable]
name=nginx stable repo
baseurl=https://nginx.org/packages/centos/$releasever/$basearch/
gpgcheck=1
enabled=1
gpgkey=https://nginx.org/keys/nginx_signing.key
module_hotfixes=true
[nginx-mainline]
name=nginx mainline repo
baseurl=https://nginx.org/packages/mainline/centos/$releasever/$basearch/
gpgcheck=1
enabled=0
gpgkey=https://nginx.org/keys/nginx_signing.key
module_hotfixes=trueFor example, open the file with a text editor:
sudo vi /etc/yum.repos.d/nginx.repoPaste the complete configuration, save it, and exit. Check the details before continuing:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
- The stable section has
enabled=1. - The mainline section has
enabled=0unless you intentionally plan to use mainline. - Both sections use
gpgcheck=1. - Both sections reference the NGINX signing key at https://nginx.org/keys/nginx_signing.key.
- The base URLs retain
$releaseverand$basearch; do not replace them with an arbitrary version or architecture.
The stable package location is represented by https://nginx.org/packages/centos/$releasever/$basearch/. Mainline uses the corresponding path under https://nginx.org/packages/mainline/centos/$releasever/$basearch/.
Step 2: Refresh metadata and install NGINX
Refresh package metadata before installing. This matters because the package manager must read the newly added repository and its current package information.
sudo dnf update
sudo dnf install nginxThe official package instructions also show sudo yum install nginx. On CentOS 8, use dnf as the normal successor command; the repository configuration and package name remain the same.
During installation, the package manager may ask whether to import the NGINX signing key. Do not accept a key solely because the prompt appears during an otherwise successful install. Verify it as described in the next section first.
Step 3: Verify the NGINX signing key before accepting it
Repository signature checking is enabled by gpgcheck=1. When the package manager presents a key-import prompt, inspect the displayed fingerprint and compare it with the fingerprints published in the NGINX installation guide. Accept the key only when the fingerprint matches the official value.
- Read the fingerprint shown by
dnfin the import prompt. - Obtain the expected NGINX signing-key fingerprint from the current NGINX installation documentation, using the key reference configured in the repository file.
- Compare every character, including the full length of the fingerprint. Do not rely on a shortened beginning or on the key name alone.
- If the values match, approve the import and allow installation to continue.
- If they do not match, decline the prompt or stop the command. Recheck the repository file, the server’s network path and the documentation before trying again.
A key mismatch is a stop condition, not a warning to ignore. Do not disable gpgcheck to work around it, and do not substitute an unverified key from an unrelated location.
Step 4: Enable mainline only when you have chosen it
If your deployment requires the mainline channel, enable it before installing or updating NGINX:
sudo dnf config-manager --enable nginx-mainlineThen install the package if it is not already present:
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →sudo dnf install nginxThe repository file still contains the stable section as the published default. Enabling mainline changes which configured channel is active for package operations; it does not create a separate executable or a second NGINX service. Record the channel choice with your deployment configuration so future administrators know why mainline was selected.
If you are moving an existing installation between channels, review the resulting package selection and test the configuration and modules after the change. The official guidance does not guarantee that every third-party or packaged module behaves identically across release streams.
Step 5: Start NGINX and verify a local HTTP response
Start NGINX with the documented command:
sudo nginxImmediately perform a local request against the loopback address:
curl -I 127.0.0.1A successful default response begins with:
HTTP/1.1 200 OKThe -I option requests response headers, so this check confirms that an HTTP listener answered without downloading a page body. Testing 127.0.0.1 isolates the NGINX process from DNS and most external network variables. Once this succeeds, test the server’s intended hostname or external address separately if your deployment requires remote access.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Where NGINX keeps its configuration and logs
Main configuration file
The default main configuration file is:
/etc/nginx/nginx.confUse this path when you need to inspect the top-level settings, included virtual-host files or worker configuration. Keep a backup before making substantial edits so you can restore the last known-good version.
Access and error logs
NGINX writes its default logs under:
/var/log/nginx/The two standard files are:
/var/log/nginx/access.log— records requests received by NGINX./var/log/nginx/error.log— records startup, configuration and request-processing errors.
When a local request fails, inspect the error log first, then correlate the timestamp with the access log. A refusal from curl points you toward startup or listener problems; an HTTP error response means NGINX answered and the next clues are usually in the configuration or error log.
Inspect the compiled paths when a package differs
Most repository installations use the paths above, but a package can be built with different configure-time locations. Display the compiled configure arguments with:
nginx -V 2>&1 | awk -F: '/configure arguments/ {print $2}' | xargs -n1Review the output when a file is not where the default layout predicts, when a module cannot be found, or when an administrator has mixed packages from different sources. The command helps distinguish an unexpected path from a failed installation.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesInstall a packaged dynamic module
If your application needs a dynamic module supplied by the NGINX package repository, install it by name using this pattern:
sudo dnf install nginx-module-<NAME>Replace <NAME> with the module’s actual package name. Install modules from the same release channel as the NGINX package whenever possible, then verify that the configuration loads the module correctly before sending production traffic. A module package is an addition to the open-source installation; it does not convert the installation to NGINX Plus.
Troubleshooting common installation failures
The package manager cannot find nginx
Confirm that /etc/yum.repos.d/nginx.repo exists and that the stable section is enabled. Re-run sudo dnf update so the package manager refreshes metadata after the file was created. Check the base URL for spelling, preserve the $releasever and $basearch variables, and make sure the machine can reach the NGINX repository.
The signing-key fingerprint does not match
Stop the installation. Verify that the repository points to the NGINX key URL and compare the complete fingerprint with the current official documentation. Do not turn off GPG checking and do not approve a key with an unverified fingerprint. If the mismatch persists, investigate whether the repository file was changed or whether a network intermediary is returning unexpected content.
Mainline was installed unintentionally
Open the repository file and inspect the enabled values. Stable should be enabled=1 and mainline should be enabled=0 when stable is intended. After correcting the file, refresh metadata and review the package operation before accepting updates. Test the resulting NGINX build and modules rather than assuming that changing the flag alone proves the active package source.
curl -I 127.0.0.1 reports connection refused
Check whether the start command completed without an error, then inspect /var/log/nginx/error.log. A syntax problem, missing module or port conflict can prevent NGINX from opening its listener. If the package uses non-default compiled paths, inspect nginx -V as shown above before editing files based on assumptions.
The response is not HTTP/1.1 200 OK
NGINX is responding, so separate an HTTP configuration issue from a process-start issue. Read the error log, inspect /etc/nginx/nginx.conf, and confirm that the request is reaching the expected server configuration. The documented default check expects a response beginning with HTTP/1.1 200 OK; a different status requires examining the active configuration and request path.
A module cannot be loaded
Confirm that the module package name follows nginx-module-<NAME>, that it was installed from the intended channel, and that the package’s compiled paths match the NGINX binary. Use nginx -V 2>&1 | awk -F: '/configure arguments/ {print $2}' | xargs -n1 to investigate path differences, then consult the error log for the exact load failure.
Operational checklist after installation
- Confirm the host is CentOS 8 and that the administrator has sudo access.
- Review
/etc/yum.repos.d/nginx.repoand document whether stable or mainline is enabled. - Run
sudo dnf updatebefore installation so repository metadata is current. - Install with
sudo dnf install nginx. - Verify the signing-key fingerprint before approving a key import.
- Start NGINX with
sudo nginx. - Run
curl -I 127.0.0.1and confirm the expectedHTTP/1.1 200 OKresponse. - Record the configuration path
/etc/nginx/nginx.confand log directory/var/log/nginx/for whoever maintains the server. - If modules are required, install matching
nginx-module-<NAME>packages and test the resulting configuration.
Open Source NGINX versus NGINX Plus
The commands in this guide install NGINX Open Source from the public repository. NGINX Plus is a separately licensed product with a separate repository and credential model. A Plus subscription is required before following Plus-specific installation instructions; adding the open-source repository does not install or activate Plus.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
