How to Build NGINX from Source on Ubuntu Linux

Building NGINX from source on Ubuntu gives you complete control over your web server configuration. Unlike package manager installations, compiling from source lets you enable specific modules (like HTTP/2, SSL, gzip compression), integrate third-party extensions, and access the latest features before they reach stable repositories. Whether you need custom SSL configurations for enterprise deployments, want to strip unnecessary modules for minimal attack surface, or need cutting-edge performance optimizations unavailable in standard packages, building from source delivers the flexibility package installations cannot match.

This guide covers installing build dependencies, downloading the NGINX source, configuring compilation options with module selection, compiling and installing the binary, creating a systemd service (Ubuntu’s init system that manages services much like Windows Services) for automatic startup, and verifying your custom NGINX installation works correctly.

When building NGINX from source, you assume responsibility for security updates and patches. Unlike package manager installations that receive automatic security updates through system repositories, source-built installations require manual monitoring of NGINX security advisories and recompilation when vulnerabilities are disclosed. Establish a process for tracking the NGINX security mailing list and rebuilding promptly when critical patches are released.

Choose Your NGINX Installation Method

Ubuntu offers multiple ways to install NGINX: through APT package repositories (APT is Ubuntu’s package manager, similar to Windows Update), building from source, or using third-party repositories like the official NGINX repository. Each approach serves different needs and involves distinct trade-offs.

Method	Version/Channel	Stability	Best For
APT Repository	Ubuntu LTS repositories	Vendor-tested packages with automatic security updates	Standard web servers that prioritize simplicity over customization
Official NGINX Repo	NGINX Inc. stable or mainline branches	Maintained by NGINX with faster feature rollouts than Ubuntu	Production workloads that need newer releases while keeping apt management
Build from Source	Tarballs downloaded from nginx.org	Depends on your maintenance cadence; you handle every patch	Deployments requiring custom modules, tuned binaries, or third-party patches

Building from source makes sense when you need third-party modules unavailable in repositories, want to strip unnecessary modules for a minimal attack surface, require cutting-edge features before they reach stable packages, or need custom SSL configurations with specific OpenSSL versions. The official NGINX repository offers a middle ground, providing recent versions with automatic updates while sacrificing module flexibility.

For most production deployments running standard configurations, the official NGINX repository delivers better security maintenance with minimal trade-offs. Reserve source builds for scenarios where repository packages cannot satisfy your technical requirements. If you decide a repository-managed install is a better fit, follow our How to Install NGINX on Ubuntu Linux guide for the apt-based workflow.

Install Build Dependencies

Update Ubuntu Before Building NGINX

To kick off the NGINX source installation on Ubuntu, start by updating and upgrading your system. This step ensures that all your system’s packages are current, minimizing potential compatibility issues.

Press Ctrl+Alt+T to open the Terminal (Ubuntu’s equivalent to Windows PowerShell) so you can run the commands in this guide.

Execute the following command in your terminal to update and upgrade your system:

sudo apt update && sudo apt upgrade

Install Required Compilation Packages

With your system up to date, install the packages needed for NGINX compilation. These include compilers and libraries required to build NGINX from source.

To install the required dependencies, run the following command:

sudo apt install build-essential libpcre3-dev libssl-dev zlib1g-dev libgd-dev

The command installs several packages, each serving a specific role in the NGINX compilation process:

• build-essential: Includes the GCC compiler and related tools required for compiling software from source.
• libpcre3-dev: Provides libraries for Perl 5 Compatible Regular Expression support, needed for URL rewriting and other NGINX functions.
• libssl-dev: Offers libraries for SSL/TLS support, ensuring secure data transmission.
• zlib1g-dev: Required for compression features, helping improve NGINX’s performance and speed.
• libgd-dev: Supports image processing capabilities, enabling NGINX to perform image manipulations directly.

Install Optional Dependencies for Advanced Modules

Beyond the core dependencies, additional libraries enable specialized NGINX modules for XML processing, geolocation, and extended image format support. Install these optional packages only when you plan to enable their corresponding modules:

sudo apt install libxml2-dev libxslt1-dev libgeoip-dev

These optional libraries enable the following modules:

• libxml2-dev: Required for the XSLT module (--with-http_xslt_module) that transforms XML responses using stylesheets.
• libxslt1-dev: Works with libxml2 to provide complete XSLT transformation capabilities.
• libgeoip-dev: Enables the GeoIP module (--with-http_geoip_module) for creating variables based on client IP addresses and MaxMind databases.

Skip these packages if you don’t need the specialized functionality they provide. Install them later if you decide to rebuild NGINX with additional modules.

Download NGINX Source Code

Select the NGINX Version

After installing the required dependencies, proceed to download the NGINX source code. Visit the NGINX website to select the version that suits your needs. You can choose from the mainline, stable, or any specific version. Mainline versions are updated regularly with the latest features and improvements, while stable versions focus on well-tested stability for production environments.

Download the Source Code

To download the selected version of NGINX, use the wget command. Define an environment variable with the version you copied from the download page (replace 1.27.2 with the release you actually want), then download the matching tarball:

NGINX_VERSION=1.27.2
wget https://nginx.org/download/nginx-${NGINX_VERSION}.tar.gz

NGINX offers two release channels: mainline (recommended for most users, updated every few months with new features, improvements, and security patches) and stable (receives only critical bug fixes, suited for conservative production environments). Replace the version placeholder in later commands with your chosen release number from the official download page. Building from source requires manual version tracking, so check the NGINX download page regularly to stay current with security fixes.

Extract NGINX Source Code

Extract the NGINX Tarball

After downloading the NGINX source code, extract the files from the tarball. Use the tar command with the appropriate flags to extract the content.

Here’s how you do it, using the NGINX_VERSION variable you set earlier:

tar -xzvf nginx-${NGINX_VERSION}.tar.gz

This command breaks down as follows:

• x: Extract the files.
• z: Uncompress the archive using gzip.
• v: Verbose mode to show the extraction process.
• f: Specify the filename of the archive.

Change to the NGINX Directory

After extracting the files, change into the directory where the NGINX source has been unpacked. This step prepares you to begin the compilation process.

Use the cd command to move into the extracted NGINX directory:

cd nginx-${NGINX_VERSION}

How the NGINX Compilation Process Works

Building NGINX from source involves three main steps: configuring build options, compiling the source code, and installing the binary. Understanding each step helps you customize your installation and troubleshoot issues if they arise.

The Three Compilation Steps

1. Configure (./configure): This script analyzes your system, checks for required dependencies, and generates a Makefile based on your specified options. You can enable or disable modules, set installation paths, and define compilation flags. The configure step does not modify your system; it only prepares the build environment.

2. Compile (make): This command reads the generated Makefile and compiles the NGINX source code into a binary executable. The compilation process creates object files in the objs directory and links them into the final NGINX binary. Depending on your system’s CPU and selected modules, this step can take several minutes.

3. Install (make install): This command copies the compiled binary, configuration files, and related resources to the installation paths you specified during configuration (or to default locations like /usr/local/nginx/). This step requires root privileges since it modifies system directories.

Common Configuration Options

The ./configure script accepts numerous flags to customize your build. Here are the most commonly used options organized by purpose:

Purpose	Option	What It Does
Installation Paths	--prefix=/path	Set base installation directory (default: /usr/local/nginx)
	--sbin-path=/path	Set NGINX binary location (default: prefix/sbin/nginx)
	--conf-path=/path	Set main configuration file location
Core Modules	--with-http_ssl_module	Enable HTTPS support with SSL/TLS
	--with-http_v2_module	Enable HTTP/2 protocol support
	--with-http_v3_module	Enable HTTP/3 protocol support (requires a QUIC-capable TLS stack such as quictls or BoringSSL plus extra build flags)
	--with-http_gzip_static_module	Serve pre-compressed .gz files
	--with-http_realip_module	Get real client IP behind proxies
	--with-http_stub_status_module	Enable basic status monitoring endpoint
Third-Party	--add-module=/path	Include external module from specified path
	--add-dynamic-module=/path	Build external module as loadable .so file
Performance	--with-pcre	Use PCRE library for regex (faster URL rewriting)
	--with-pcre-jit	Enable JIT compilation for PCRE (even faster)
	--with-file-aio	Enable asynchronous file I/O for large files
	--with-threads	Enable thread pool support for better performance
Security	--user=www-data	Set unprivileged user for worker processes
	--group=www-data	Set group for worker processes
Debugging	--with-debug	Enable debug logging (increases binary size)

For a complete list of available options, run ./configure --help in the NGINX source directory.

Manage Dynamic Modules at Runtime

NGINX supports two ways to include modules: statically compiled into the binary or dynamically loaded at runtime. Dynamic modules offer flexibility because you can enable or disable them without recompiling NGINX.

To build a module as dynamic rather than static, append =dynamic to the module flag during configuration:

./configure --with-http_image_filter_module=dynamic --modules-path=/etc/nginx/modules

This creates a .so shared library file in the modules directory instead of linking the module directly into the NGINX binary. After compilation, load dynamic modules in your nginx.conf file using the load_module directive at the top level (before the events block):

load_module modules/ngx_http_image_filter_module.so;

events {
    worker_connections 1024;
}

http {
    # Your HTTP configuration
}

Dynamic modules reduce the main binary size and allow you to test modules in production without a complete rebuild. Remove or comment the load_module line to disable a module, then reload NGINX configuration. This approach particularly benefits environments where you experiment with different module combinations or maintain multiple configurations across servers.

Configure Build Options

Set Configuration Options

When building NGINX from source, configure your build options to match your specific needs. Use the ./configure command to set paths and enable various modules. The following example mirrors Ubuntu’s packaged layout so the binary, configuration files, logs, and cache directories land in familiar locations:

./configure \
  --prefix=/etc/nginx \
  --sbin-path=/usr/sbin/nginx \
  --modules-path=/usr/lib/nginx/modules \
  --conf-path=/etc/nginx/nginx.conf \
  --http-log-path=/var/log/nginx/access.log \
  --error-log-path=/var/log/nginx/error.log \
  --pid-path=/run/nginx.pid \
  --lock-path=/var/lock/nginx.lock \
  --http-client-body-temp-path=/var/cache/nginx/client_temp \
  --http-proxy-temp-path=/var/cache/nginx/proxy_temp \
  --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp \
  --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp \
  --http-scgi-temp-path=/var/cache/nginx/scgi_temp \
  --user=www-data \
  --group=www-data \
  --with-threads \
  --with-file-aio \
  --with-http_ssl_module \
  --with-http_v2_module \
  --with-http_gzip_static_module \
  --with-http_realip_module \
  --with-http_stub_status_module \
  --with-http_image_filter_module=dynamic \
  --with-stream=dynamic \
  --with-http_mp4_module \
  --with-http_slice_module \
  --with-pcre-jit

This command keeps configuration files in /etc/nginx, writes logs to /var/log/nginx, stores temporary cache data under /var/cache/nginx, and installs the binary in /usr/sbin just like the Ubuntu package. It also pins the runtime user to www-data and enables common modules (SSL, HTTP/2, gzip, status, stream) so the rest of the guide, including the provided systemd unit, works without extra path edits.

Customize Your NGINX Build

The ./configure script allows extensive customization. Here’s how you can customize your NGINX installation to meet specific requirements:

Real-World Configuration Examples

Different deployment scenarios require different module combinations. These examples demonstrate practical configurations for common use cases:

High-Performance Reverse Proxy:

./configure \
  --with-http_ssl_module \
  --with-http_v2_module \
  --with-http_realip_module \
  --with-http_stub_status_module \
  --with-pcre-jit \
  --with-threads

This configuration suits load balancers and reverse proxies that terminate SSL, need to identify client IPs behind CDNs (realip), and require performance monitoring (stub_status). The pcre-jit and threads options optimize for high request volumes.

Media Streaming Server:

./configure \
  --with-http_mp4_module \
  --with-http_flv_module \
  --with-file-aio \
  --with-threads \
  --with-http_slice_module

Media servers benefit from pseudo-streaming support (mp4/flv modules), asynchronous I/O for large files, and the slice module for efficient caching of video segments. These modules reduce disk I/O bottlenecks when serving concurrent video streams.

Minimal Security-Focused Build:

./configure \
  --with-http_ssl_module \
  --with-http_v2_module \
  --without-http_autoindex_module \
  --without-http_browser_module \
  --without-http_memcached_module \
  --without-http_empty_gif_module

This approach strips unnecessary modules to reduce attack surface while maintaining modern protocol support. Each disabled module represents code that cannot introduce vulnerabilities, making this configuration appropriate for security-conscious deployments where only SSL termination and content delivery matter.

Additional Configuration Examples

To enable HTTP/2 support and integrate the PCRE library, which is crucial for processing regular expressions in NGINX, use the following configuration:

./configure --with-http_v2_module --with-pcre

If you need to define the installation directory for NGINX, you can set it using the --prefix option. For instance, to install NGINX in the /usr/local/nginx directory, the command would be:

./configure --prefix=/usr/local/nginx

For incorporating additional modules such as ngx_cache_purge, the --add-module option comes into play. To include this module, the configuration would look like this:

./configure --add-module=/path/to/ngx_cache_purge

Including extra libraries like libxslt or libssl is straightforward with the --with-XXX-module option. To include these libraries, the respective commands would be:

./configure --with-libxslt-module
./configure --with-openssl=/path/to/openssl

To activate modules such as SSL and the real IP module, the configuration commands would be:

./configure --with-http_ssl_module
./configure --with-http_realip_module

These configurations demonstrate just a few ways you can use the ./configure script to customize your NGINX build.

For a comprehensive list of all available options, you can run ./configure --help. This command provides detailed information on all the flags and options you can use to optimize your NGINX installation.

Build HTTP/3 with a QUIC-Capable TLS Stack

The --with-http_v3_module flag only succeeds when you compile NGINX against a TLS library that understands QUIC. The easiest option is quictls, a fork of OpenSSL maintained by the NGINX team. Download the matching archive, extract it next to the NGINX source directory, and point ./configure to that path:

# Example versions — update them to the latest tags from nginx.org and quictls
NGINX_VERSION=1.27.2
QUICTLS_TAG=openssl-3.0.13-quic1

wget https://nginx.org/download/nginx-${NGINX_VERSION}.tar.gz
wget https://github.com/quictls/openssl/archive/refs/tags/${QUICTLS_TAG}.tar.gz

tar -xzvf nginx-${NGINX_VERSION}.tar.gz
tar -xzvf ${QUICTLS_TAG}.tar.gz

# Set this variable to the folder name created by the tar command (GitHub archives prepend "openssl-")
QUICTLS_DIR=openssl-openssl-3.0.13-quic1

cd nginx-${NGINX_VERSION}
./configure \
  --with-http_v3_module \
  --with-openssl=../${QUICTLS_DIR} \
  --with-cc-opt="-I../${QUICTLS_DIR}/include" \
  --with-ld-opt="-L../${QUICTLS_DIR} -Wl,-rpath,../${QUICTLS_DIR}"
make
sudo make install

Adjust the path names if quictls changes tag formats. Without this QUIC-enabled dependency, ./configure fails with “requires OpenSSL QUIC support” errors, so avoid the HTTP/3 flag unless you are ready to maintain the extra library.

Performance Optimization Options

Beyond basic functionality, several configuration options significantly improve NGINX performance under high load or when serving large files. These optimizations leverage modern CPU features and asynchronous I/O capabilities.

Enable PCRE JIT Compilation

The PCRE library handles regular expressions in location blocks, rewrites, and other directives. Just-in-time compilation accelerates regex matching by converting patterns into native machine code:

./configure --with-pcre-jit

This option delivers substantial performance gains for configurations with complex location matching or extensive rewrite rules, particularly when handling thousands of requests per second. The speed improvement becomes noticeable when regular expressions run repeatedly across many connections.

Enable Thread Pools

Thread pools prevent blocking operations from stalling NGINX’s event loop. Without threads, reading large files from slow disks can freeze worker processes. Thread pools offload these blocking operations:

./configure --with-threads

After enabling thread pools during compilation, activate them in your NGINX configuration for specific locations serving large static files, video content, or when disk I/O becomes a bottleneck. This separation keeps the main event loop responsive even when serving multi-gigabyte files.

Enable Asynchronous File I/O

Asynchronous file I/O leverages kernel-level AIO support on Linux and FreeBSD, allowing NGINX to initiate multiple read operations without waiting for each to complete:

./configure --with-file-aio

This optimization particularly benefits servers delivering large static files (videos, images, software downloads) where disk I/O dominates request latency. Combine with thread pools for maximum effectiveness when serving content from traditional spinning disks rather than SSDs.

Combine Performance Options

For high-performance production deployments, combine multiple optimization flags in a single configuration command:

./configure \
  --with-pcre-jit \
  --with-threads \
  --with-file-aio \
  --with-http_v2_module \
  --with-http_ssl_module

This combination enables regex acceleration, non-blocking file operations, and modern protocol support, creating a foundation for handling heavy traffic loads efficiently.

Compile and Install NGINX

Compile NGINX

After setting the configuration options for NGINX, start the compilation process with the make command. This command compiles the NGINX source code based on the parameters defined in the ./configure script. The compilation process creates the NGINX binary executable, typically found in the objs directory.

make

Install NGINX

After compiling NGINX, install it using sudo make install. This command installs the NGINX binary, configuration files, and additional necessary files to the specified prefix path. If you haven’t defined a different location during configuration, NGINX installs to /usr/local/nginx/ by default.

sudo make install

Following the installation, you will find NGINX in the sbin directory within the designated prefix path, ready for further configuration and use.

Configure NGINX Runtime Environment

Create Required Cache Directories

Before starting NGINX, create the cache directories referenced in your configuration. The build process configured these paths during the ./configure step, but the directories don’t exist yet:

sudo mkdir -p /var/cache/nginx/client_temp \
             /var/cache/nginx/proxy_temp \
             /var/cache/nginx/fastcgi_temp \
             /var/cache/nginx/uwsgi_temp \
             /var/cache/nginx/scgi_temp

Set ownership to the www-data user so NGINX worker processes can write temporary files:

sudo chown -R www-data:www-data /var/cache/nginx

Without these directories, NGINX will fail to start with “failed (2: No such file or directory)” errors when attempting to cache proxy responses or handle client request bodies.

Create NGINX SystemD Service

After creating the required directories, manage NGINX as a service using systemd. This allows you to start, stop, and restart NGINX like any other Ubuntu service.

Create a SystemD Service File for NGINX

To set up a systemd service for NGINX, create a new service file:

sudo nano /etc/systemd/system/nginx.service

In this file, input the following details, ensuring that you replace /path/to/nginx with the actual path to your NGINX binary if it is not located at /usr/sbin/nginx:

[Unit]
Description=The NGINX HTTP and reverse proxy server
After=syslog.target network-online.target remote-fs.target nss-lookup.target
Wants=network-online.target
        
[Service]
Type=forking
PIDFile=/var/run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t
ExecStart=/usr/sbin/nginx
ExecReload=/usr/sbin/nginx -s reload
ExecStop=/bin/kill -s QUIT $MAINPID
PrivateTmp=true
        
[Install]
WantedBy=multi-user.target

This configuration sets up NGINX as a service, defining how it should start, stop, and reload, and ensures it launches after the network is online.

Reload SystemD to Recognize the New Service

After defining the service, update systemd to recognize your new NGINX service:

sudo systemctl daemon-reload

Start and Enable NGINX Service

With the systemd service in place, start the NGINX service:

sudo systemctl start nginx

To ensure NGINX starts automatically on boot, enable the service:

sudo systemctl enable nginx

Verify NGINX Installation

Test NGINX Functionality

After installing NGINX, verify its operation. You can access the NGINX welcome page through a web browser. Use your server’s local host address or IP address to navigate to the NGINX test page.

Open your web browser and visit http://localhost to access the NGINX welcome page directly from the same machine.

Verify Using IP Address

If accessing the localhost doesn’t display the NGINX welcome page, browse to http://203.0.113.10 (replace the example IP with your server’s actual address) from another system on the network.

When you access these URLs, you should see the default NGINX welcome page, indicating that NGINX is installed and running correctly on your Ubuntu server. If the page doesn’t appear, ensure that NGINX is running and that no firewall rules block access to the service. Check your UFW firewall configuration if you cannot reach the welcome page from a remote connection.

Check NGINX Version and Compiled Modules

To confirm which version you built and verify which modules were compiled into your NGINX binary, run the following command:

nginx -V

This command displays the NGINX version number followed by a detailed list of all configure arguments used during compilation. The output shows exactly which modules are enabled, whether they’re static or dynamic, and the paths configured during the build process. This verification step confirms your custom build matches the configuration options you specified.

Troubleshooting Common Build Issues

Building NGINX from source can occasionally encounter problems during configuration, compilation, or installation. Understanding common issues helps you resolve them quickly and complete your installation successfully.

Missing Development Libraries

The most frequent build failures occur when the configure script cannot find required development libraries. If you see errors like “not found” or “checking for library… not found,” install the missing package.

Common missing libraries and their solutions:

# PCRE library missing
sudo apt install libpcre3-dev

# SSL/TLS library missing
sudo apt install libssl-dev

# zlib compression library missing
sudo apt install zlib1g-dev

# GD library for image processing missing
sudo apt install libgd-dev

After installing missing libraries, rerun the configure command from the NGINX source directory.

OpenSSL Version Conflicts

When enabling SSL or HTTP/2 modules, version mismatches between the installed OpenSSL library and NGINX requirements can cause compilation failures. Modern NGINX versions require OpenSSL 1.1.1 or later for HTTP/2 support, and OpenSSL 3.0+ for HTTP/3.

Check your OpenSSL version:

openssl version

If your system’s OpenSSL version is too old, either upgrade your system packages or compile NGINX with a specific OpenSSL version using the --with-openssl=/path/to/openssl-source flag during configuration.

Permission Denied During Installation

The make install command requires root privileges because it copies files to system directories. If you encounter “Permission denied” errors, ensure you’re using sudo:

sudo make install

Alternatively, if you configured NGINX with a custom prefix in your home directory or another location where you have write permissions, you may not need sudo.

Configuration Test Failures

After installation, NGINX won’t start if the configuration file contains syntax errors. Test your configuration before starting the service:

sudo nginx -t

This command validates the configuration and reports the exact line number of any syntax errors. Common issues include missing semicolons, mismatched brackets, or incorrect directive names. Fix reported errors in /etc/nginx/nginx.conf (or your custom config path) and retest until the validation passes.

Port Already in Use

If NGINX fails to start with “bind() to 0.0.0.0:80 failed” errors, another service is already using port 80 or 443. Check which process is using the port:

sudo ss -tlnp | grep :80

Stop the conflicting service (often Apache) or configure NGINX to use different ports in the configuration file before starting.

Upgrade Source-Built NGINX

Upgrading a source-built NGINX installation requires careful planning to avoid service disruption. Unlike package manager installations that handle upgrades automatically, source builds need manual intervention to apply security patches or adopt new features.

Backup Current Configuration

Before upgrading, preserve your working configuration and note your current build options. Extract the exact configure arguments from your running NGINX:

nginx -V 2>&1 | grep "configure arguments"

Copy this output to a text file so you can replicate the same modules and paths in the upgraded version. Back up your configuration files:

sudo cp -r /etc/nginx /etc/nginx.backup-$(date +%Y%m%d)

Download and Build New Version

Download the newer NGINX version you want to install, extract it, and navigate into the source directory:

wget https://nginx.org/download/nginx-x.x.x.tar.gz
tar -xzvf nginx-x.x.x.tar.gz
cd nginx-x.x.x

Replace each x.x.x placeholder with the specific version number you are upgrading to so the download, extraction, and directory names all match.

Run configure using the exact same arguments from your backup (paste the arguments you saved earlier), then compile:

./configure [paste your saved configure arguments here]
make

Test Configuration Before Installing

Before replacing your production binary, verify the new build works with your existing configuration. Test the compiled binary directly from the build directory:

sudo ./objs/nginx -t -c /etc/nginx/nginx.conf

This command tests your current configuration file against the new NGINX binary without installing anything. If the test passes, proceed with installation. If errors appear, resolve configuration incompatibilities before continuing.

Install and Gracefully Reload

Install the new binary over the existing one:

sudo make install

The installation replaces the NGINX binary but preserves your configuration files. Perform a graceful reload to switch to the new version without dropping connections:

sudo nginx -t
sudo systemctl reload nginx

Verify the upgrade succeeded by checking the running version:

nginx -v

Monitor your logs and server metrics for several hours after upgrading to catch any unexpected behavior. Keep the source directory and your configuration backup until you confirm the upgrade works correctly.

Additional Tips for Building NGINX

Compile NGINX with Additional Modules

Enhance NGINX’s capabilities by including extra modules during the compilation process. For instance, if you want to add the NGINX HTTP push module, use the --add-module flag during the configuration step. Follow these commands to compile NGINX with the HTTP push module:

./configure --add-module=/path/to/nginx-http-push-module
make
sudo make install

Replace /path/to/nginx-http-push-module with the actual path to the module you wish to include.

Compile Dependencies from Source

For maximum control over your NGINX build, compile critical dependencies (PCRE, zlib, OpenSSL) from source rather than using system libraries. This approach ensures specific versions, applies custom patches, and guarantees consistency across different Ubuntu releases.

Download the source tarballs for each dependency, extract them, then reference their paths during NGINX configuration:

# Download dependencies
wget https://github.com/PCRE2Project/pcre2/releases/download/pcre2-10.42/pcre2-10.42.tar.gz
wget https://www.openssl.org/source/openssl-3.0.13.tar.gz
wget https://zlib.net/zlib-1.3.tar.gz

# Extract all archives
tar -xzvf pcre2-10.42.tar.gz
tar -xzvf openssl-3.0.13.tar.gz
tar -xzvf zlib-1.3.tar.gz

# Configure NGINX with source paths
cd nginx-x.x.x
./configure \
  --with-pcre=../pcre2-10.42 \
  --with-pcre-jit \
  --with-openssl=../openssl-3.0.13 \
  --with-zlib=../zlib-1.3 \
  --with-http_ssl_module \
  --with-http_v2_module

make
sudo make install

NGINX compiles these libraries statically into the binary, eliminating runtime dependencies on system versions. This technique proves particularly valuable when you need OpenSSL 3.x for HTTP/3 support but your Ubuntu release ships an older version, or when you want PCRE2 with JIT compilation optimizations not available in standard packages. The trade-off is larger binary size and responsibility for patching these bundled libraries when security issues arise.

Manage NGINX with Systemctl Commands

On Ubuntu, managing the NGINX service is straightforward with systemctl commands. Here’s how to control the NGINX service using the terminal:

Start NGINX:

sudo systemctl start nginx

Stop NGINX:

sudo systemctl stop nginx

Restart NGINX:

sudo systemctl restart nginx

Reload NGINX:

sudo systemctl reload nginx

NGINX Status Check

sudo systemctl status nginx

Enable NGINX on System-Boot

sudo systemctl enable nginx

Disable NGINX on System-Boot:

sudo systemctl disable nginx

Conclusion

Building NGINX from source delivers complete control over module selection, compilation flags, and installation paths that package managers cannot provide. The compilation process covers dependency installation, source download with version selection, configuration with custom flags (SSL, HTTP/2, compression modules), binary compilation, cache directory creation, and systemd service integration for automatic startup. Your custom-built NGINX now runs with precisely the features you need, whether that’s third-party modules, performance optimizations, or security-hardened configurations unavailable in standard repositories.