# NGINX source repository: building the web server, reverse proxy and load balancer from upstream > The nginx/nginx repository is the upstream C source for NGINX, not the distro package. It covers how the master and worker process model works, how to build from source, and when the packaged build is the better choice. **nginx/nginx** — NGINX is the source for the web server and reverse proxy used to serve, route, and balance high-traffic applications. - Repository: https://github.com/nginx/nginx - Website: https://nginx.org/ - Stars: 31,765 · Forks: 8,311 - Language: C - License: BSD-2-Clause - Published: 2026-08-08 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/nginx-nginx ## What nginx/nginx actually is, and who ends up here This repository holds the C source of NGINX itself: the web server, reverse proxy, load balancer, API gateway and content cache that the README describes as free and open source software under a simplified 2-clause BSD-like licence. It is not a wrapper, a configuration generator, or a control panel. If you arrived looking for a UI to click through, you are in the wrong repository; the related searches for nginx proxy manager point at a different project entirely. The people who belong here fall into a few groups. Distributors and packagers who need to build NGINX for a platform the official binaries do not cover. Operators who need a module that is not compiled into the packaged build. And anyone who wants to read the source rather than trust a changelog. Everyone else, which is most people running a website, is better served by the official packages the README points to, and it says so directly: it advises installation and usage of official packages or sources from this repository rather than the community version shipped by nearly all popular Linux distributions, because the official route keeps you on the most recent release, including the latest features, fixes and security patches. ## Master and worker processes, and why shared memory zones matter The runtime design is the part worth understanding before you touch a config file. NGINX does not run as one monolithic process. The README describes a collection of processes: a master process that maintains worker processes and reads and evaluates configuration files, and one or more worker processes that handle the actual data, such as HTTP requests. The number of workers is set by the worker_processes directive and can be fixed for a given configuration or adjusted automatically to the number of available CPU cores. The README's own position is that the automatic option usually balances load best, since NGINX is designed to distribute work across all worker processes. Here is the consequence that catches people out. Processes synchronise through shared memory, so many directives require you to allocate a shared memory zone. Rate limiting is the clearest example: clients have to be tracked in a common memory zone so that every worker knows how many times a particular client has hit the server in a given span of time. Omit the zone and the directive has nothing to count against. This is also why a configuration that behaves correctly with one worker can behave differently once you scale workers up, and why the zone size you pick is a real capacity decision rather than a formality. ## Modules decide which directives exist in your build NGINX is assembled from individual modules, each adding configurable features. Modules are either static, meaning they are defined at build time and compiled into the resulting binaries, or dynamic, meaning they can be added to an existing installation. The README links to a Dynamic Modules section for how those work and how to obtain, install and configure them. This is the single most common source of confusion when copying a configuration from a tutorial or a colleague. The README states plainly that the set of directives available to your distribution of NGINX depends on which modules have been made available to it. A directive that works on one machine can fail to parse on another, and the error is a configuration error, not a syntax mistake on your part. The diagnostic is a one-liner. The README gives this command to see which static modules your NGINX binaries were built with: ```bash nginx -V ``` That output tells you immediately whether the feature you are configuring is present. The README also points at the Configuring the build section for how to include specific static modules in your own build, which is the path you take when the packaged binary is missing something you need. ## Installing NGINX and serving a first site from the upstream source The README treats precompiled binaries as the normal route and building from source as the alternative, so start there. Official Linux packages are documented separately from this repository, and the README's Linux binary installation process section is the entry point. It also splits binaries into two tracks: stable, built from stable branches and containing only critical fixes backported from mainline, and mainline, built from the master branch with the latest features and bugfixes. The README says you will need to decide which is appropriate for your purposes. Once installed, the configuration lives in text files made of directives, and the README points to Configuration File's Structure in the Beginners Guide for a comprehensive description of how those files work. The README does not reproduce a server block, so no configuration example is quoted here; the directive reference the README links to is where the individual directives are documented. For a source build, the README lays out the sequence as installing dependencies, cloning the repository, configuring the build, compiling, locating the binary and installing it, and then running and testing the installed binary. Each of those steps is described in its own section of the README, and the build options are covered under Configuring the build. ## Building from source, and the dependency work it implies The configure step is where module selection happens, and it is the reason to build at all. What the README does not do is promise that this is quick or low maintenance. Dependencies have to be present before configure will succeed, and the resulting binary is yours to track. There is no statement in the README about an automatic upgrade path for a source-built installation, and no rollback procedure is documented there. If you build from source, the upgrade mechanism is whatever your own packaging or deployment tooling provides, and the release cadence you are tracking is the one visible in the repository's release tags. That cadence is not slow. The repository shows release-1.31.4 dated 2026-08-19, with release-1.31.3 and release-1.30.4 both dated 2026-07-15. Two parallel lines are being maintained, which is consistent with the stable and mainline split described in the README. A source build means every one of those releases is a rebuild you own. ## Where NGINX from source is the wrong answer The clearest failure mode is treating this repository as a faster or more current way to run a website. It is the opposite for most operators. The README explicitly recommends official packages over the community builds that ship with nearly every popular Linux distribution, and it does not recommend hand-building as a general practice. Choosing source means you have taken on the patch cycle yourself. Security is the sharp edge. The related searches around nginx vulnerability and nginx cve reflect that people do search for this, and the README's argument for official packages is framed around staying current with fixes and security patches. A binary you compiled six months ago and forgot about is a worse position than a package that your distribution updates. The second wrong-tool case is configuration portability. If your team copies server blocks between machines without checking which modules are present, you will hit directive-not-found errors that look like typos. The nginx -V output is the fix, and it is worth making part of the handover for any environment you build yourself. Finally, if what you actually want is a management interface over NGINX, this repository will not give it to you. It ships the server, not a control plane. ## How this differs from Apache httpd The comparison people search for is nginx vs apache, and the architectural difference is the one worth stating. Apache's classic model is process or thread per connection, with modules that hook into request processing in a wide range of phases and can be enabled per-directory through .htaccess files. NGINX, as the README describes it, runs a master process plus a configurable number of worker processes, with the worker count either fixed or matched to available CPU cores, and processes coordinating through shared memory zones. That difference has practical consequences. Configuration in NGINX is centralised: the master process reads and evaluates the configuration files, so there is no equivalent of dropping a per-directory override file and having it take effect without a reload. Feature availability is a build-time property rather than something you toggle in a config file, which is why nginx -V matters. And anything that needs to be shared across workers, such as rate-limit counters, has to be placed in a shared memory zone rather than living in a single process's memory. Which is better depends on what you are running. The README does not make a comparative claim and neither should anyone reading it. ## Licence and the cost of staying current NGINX is distributed under a simplified 2-clause BSD-like licence, and the repository carries the LICENSE file at its root. That is a permissive licence, which in practice means you can redistribute and modify the source, including in commercial products, provided you meet the conditions in the file. Read the actual text rather than a summary; this article is not legal advice and the licence file is the authority. The maintenance picture is straightforward and the repository supports it. The last push to master was on 2026-08-19, matching the release-1.31.4 tag, and the previous pair of releases landed on 2026-07-15. The repository is not archived. The README also notes that enterprise distributions, commercial support and training are available from F5, Inc, which is the route for teams that want a support contract rather than a community patch cycle. If you install from official packages, upgrades are a package manager operation. If you build from source, the README does not document an upgrade or rollback procedure, so the cost is whatever rebuild pipeline you construct. Budget for that before you choose the source path, not after. ## Conclusion Adopt nginx/nginx from source if you need control over which static and dynamic modules end up in the binary, or you are packaging NGINX for a platform the official packages do not cover. Do not build it yourself if you only need a web server on a mainstream Linux distribution: the README advises installing the official packages instead, and a hand-built binary leaves you owning the security patch cycle. Verify three things before committing: whether you want the stable or the mainline branch, which modules your configuration directives depend on, and how you will rebuild when a new release lands. The repository's own answer to that last question is the build section of the documentation, not the README. ## FAQ ### What is NGINX and why is it used? The README describes NGINX as a web server, high performance load balancer, reverse proxy, API gateway and content cache. It is used to serve, route and balance traffic, and it runs as a master process plus worker processes rather than a single monolithic process. ### Is NGINX free? Yes. The README states that NGINX is free and open source software, distributed under the terms of a simplified 2-clause BSD-like licence, with the LICENSE file in the repository. Enterprise distributions, commercial support and training are sold separately by F5, Inc. ### Is NGINX end of life? No. The repository is not archived, and the most recent release, release-1.31.4, is dated 2026-08-19, with release-1.31.3 and release-1.30.4 dated 2026-07-15. Two release lines are being maintained, matching the stable and mainline split the README describes. ### How do I use NGINX as a reverse proxy or load balancer? The README covers both under Getting started, with separate sections on load balancing and on rate limiting. Configuration is done through text files of directives, and the README notes that the directives available to you depend on which modules your build includes. ### How do I install NGINX on Ubuntu? The README points to the official Linux packages rather than the community build that ships with most distributions, and its Linux binary installation process section is the entry point. It also advises choosing between the stable and mainline tracks, since stable carries only critical fixes backported from mainline. ## Sources - [Official documentation](https://nginx.org/) - [Official README](https://github.com/nginx/nginx#readme) - [Project repository](https://github.com/nginx/nginx) - [Release notes](https://github.com/nginx/nginx/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nginx-nginx