# Similarities and Differences Between Angie and nginx

*25.08.2023*

How the Angie project and the Angie PRO product relate to their predecessor,
nginx, and its commercial version NGINX Plus.

![Angie vs. nginx](../../_images/news/shodstva-i-razlichiya-angie-i-nginx.png)![Angie vs. nginx](../../_images/news/shodstva-i-razlichiya-angie-i-nginx.png)

## **Introduction**

Today we will discuss a topic that excites everyone who is getting acquainted
with our project — how the Angie project and the Angie PRO product relate to
their predecessor, nginx, and its commercial version NGINX Plus. Reading
publications in the Russian segment of the Internet, we see that these questions
are still actively discussed; we will try to shed light on everything that
generates particular interest.

TL;DR: no, we did not just change the label.

## How Angie Relates to nginx

From the very beginning, Angie has been positioned as a fork of nginx. This
concept (not to be confused with "branch" — a code branch) is perhaps one of the
cornerstones of open source software. On the other hand, it is often accompanied
by misunderstandings and misinterpretations.

A fork occurs when a new project begins based on an open-source project,
entirely or partially borrowing code from its predecessor. The borrowing itself
should hardly raise questions: this is precisely why the creators initially make
the code open. As a classic said, "Let a hundred flowers bloom, let a hundred
schools of thought contend."

The new project is often not directly related to its predecessor: it is worked
on by different people, and they have their own vision for the future.
Naturally, forks are often created by former participants of the project who
have left the team. Another typical case is the development of an open project
with the involvement of a commercial company: just think of an example like
MariaDB.

At the same time, a fork is not a static copy — if the predecessor's code is
evolving, improvements and additions regularly filter into the new project as
well. This is exactly what happens in Angie: with each new release, we "pull
in" changes (often significant) that have occurred in the open version of nginx.

Finally, we note that Angie does not contain any code from NGINX Plus, the
closed commercial version of nginx; moreover, we do not aim to make our paid web
server, [Angie PRO](https://angie.software/angie/docs/), a one-hundred-percent
functional copy of NGINX Plus. As another classic said, "We will follow a
different path."

## How Angie Substitutes nginx

Angie can serve as a full replacement for the open version of nginx, providing
the same capabilities as the corresponding release of its predecessor (more on
our own capabilities below).

At the same time, in addition to familiar operating systems and computing
architectures, Angie consciously targets platforms for which "official" nginx
will not be compiled for a while: these include certified operating systems in
Russia, such as ALT Linux, Astra Linux SE, and RED OS, as well as "Baikal" and
"Elbrus" processors.

Another difference lies in our approach to third-party modules. One of the
advantages that ensured nginx's popularity was its extensible architecture —
anyone can write a module that implements new useful functionality and freely
publish it for open access.

Over time, an entire ecosystem of such third-party modules has formed on the
Internet; however, users had to assemble them themselves. We decided to simplify
their lives and maintain a uniform assembly of [ready-made packages](https://angie.software/angie/docs/installation/oss_packages/#install-dynamicmodules-oss/) for a number
of these modules in our repositories, utilizing our experience and knowledge.

## How Angie Improves nginx

By the standards of the software industry, the nginx project was created quite
some time ago. During this time, users have accumulated numerous requests that
we strive to consider as we develop Angie in accordance with the needs of modern
dynamic IT infrastructure; put simply, we value speed, ease of configuration,
and monitoring convenience. Additionally, we aim to support standards that are
current and relevant to us.

## Standards and Certification

We adapt to the conditions in which we operate. During the existence of the
project, we have:

- localized development in Russia and entered the Unified Register of Russian
  Software for Electronic Computing Machines and Databases;
- initiated active work to support encryption in accordance with GOST;
- implemented support for a number of encryption standards used in China (and
  the authors of the library [Tongsuo](https://github.com/Tongsuo-Project/Tongsuo/) even [recommend](https://github.com/Tongsuo-Project/Tongsuo#典型应用/)
  us).

## Speed

Another factor we pay attention to in our work is accelerating the web server
itself by eliminating unnecessary delays, as well as quickly adapting to
changing working conditions. We have:

- added a dynamic configuration API and adaptive DNS addressing tools, which
  help bypass the structural limitations of the predecessor and change settings
  faster without resource overuse;
- implemented a mechanism for binding user sessions to the proxied server, which
  expands the applicability of Angie for different usage scenarios and saves
  resources;
- introduced active health probes for proxied servers, reducing the likelihood
  of sending a real request to a non-working server; this decreases delays in
  request processing and improves service quality for end users;
- created the ability to segment the proxy cache, thereby more effectively
  utilizing all server resources.

## Configurability

Another area where we aim to achieve improvements is the flexibility and ease
of configuring the web server. We have:

- added the aforementioned dynamic configuration API for groups of proxied
  servers, which simplifies Angie's integration with modern IT infrastructure,
  as well as settings that allow dynamic adaptation to changes in DNS
  addressing;
- provided a number of other settings, less extensive but quite useful.

## Observability

Finally, an important aspect of Angie's development for us is monitoring the
state of both the web server itself and the proxied servers. We have:

- implemented in the API the ability to retrieve basic information about the web
  server, as well as statistics on all key aspects of its operation in popular
  modern formats;
- introduced the aforementioned active health probes for proxied servers, which
  autonomously monitor their operational status;
- added a family of settings for collecting statistics on data transfer sessions
  and address resolution requests.

## Conclusion

We have briefly outlined what makes Angie distinctive and listed the main
priorities for further project development; we will provide more details about
our future plans, as well as our version of the Ingress Controller, separately.
We hope that now the similarities and differences between Angie and nginx will
raise fewer questions. Thank you for being with us!