Binary packages are the standard way to install software on Linux today. Some environments use ready-made container images instead. Still, knowing how to build Angie from source opens up extra options. This article walks through that non-trivial process and looks at when a source build is worth the trouble.
Video version
A video version of this article is available on YouTube.
Angie source code
The build starts with getting the source code. The simplest option is to download the Angie source archive from the official site. It hosts archives for release versions of the server, and that option is recommended for production use. For example, version 1.11.8:
curl -O "https://download.angie.software/files/angie-1.11.8.tar.gz"
Then unpack the archive however you prefer, for example:
tar -xpf angie-1.11.8.tar.gz
The second option is to pull the latest code from the repository:
git clone http://git.angie.software/web-server/angie.git
That gives you the newest version under development. This option is useful for exploring new features, running experiments, and contributing to the project.
You now have a copy of the server source, including the bundled modules. Next come configuration and installing dependencies.
Preparing to build
Before building, you need to collect information about the system and pass the settings you need. The configure script at the root of the source tree does that. Its arguments set the target server options, the build set (modules), where dependencies are searched for, and where service files are placed. The full list of options is very long and is given on the build documentation page. To make picking these options easier, you can borrow them from a ready-made Angie package. Install it on the target system (or one on the same distribution branch) and run angie -V; the options appear in the configure arguments line:
configure arguments: --prefix=/etc/angie --conf-path=/etc/angie/angie.conf --error-log-path=/var/log/angie/error.log --http-log-path=/var/log/angie/access.log --lock-path=/run/angie.lock --modules-path=/usr/lib/angie/modules --pid-path=/run/angie.pid --sbin-path=/usr/sbin/angie --http-acme-client-path=/var/lib/angie/acme --http-client-body-temp-path=/var/cache/angie/client_temp --http-fastcgi-temp-path=/var/cache/angie/fastcgi_temp --http-proxy-temp-path=/var/cache/angie/proxy_temp --http-scgi-temp-path=/var/cache/angie/scgi_temp --http-uwsgi-temp-path=/var/cache/angie/uwsgi_temp --user=angie --group=angie --with-file-aio --with-http_acme_module --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-http_v3_module --with-mail --with-mail_ssl_module --with-stream --with-stream_acme_module --with-stream_mqtt_preread_module --with-stream_rdp_preread_module --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-threads --feature-cache=../angie-feature-cache --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,--package-metadata=%7B%22type%22:%22deb%22%2C%22os%22:%22ubuntu%22%2C%22name%22:%22angie%22%2C%22version%22:%221.11.8-1~resolute%22%2C%22architecture%22:%22amd64%22%7D -flto=auto -ffat-lto-objects -Wl,-z,relro -Wl,-z,now'
These options can serve as a starting point for custom builds. Most paths and settings will match the official packaged build, which makes switching to a custom Angie version much easier.
Another way to see the options is to start a temporary container and read them from it:
docker run -it --pull always --rm docker.angie.software/angie angie -V
Keep in mind the base distribution of the container image.
You now have a baseline set of arguments for running configure. The next stage is dependencies.
Installing dependencies
Dependencies are usually libraries or other system components needed to build the web server. The build tools also have to be present. Dependencies are checked while configure runs. Run the script on a clean system and you get an error while looking for a C compiler:
./configure ...
checking for OS
+ Linux 7.0.0-22-generic x86_64
checking for C compiler ... not found
./configure: error: C compiler cc is not found
Build tools are usually not installed by default. To install the required components on Ubuntu, the build-essential meta-package is the easy way:
apt install build-essential
Run configure again after installing the package and you see the same error. Wrong package? No — the culprit is the --feature-cache=../angie-feature-cache option. It enables a cache for detecting system components and dependencies. Its main purpose is to speed up builds of many third-party module packages for the official repository. So the compiler is not searched for a second time, and the failure is reported from the cache. In most cases it is better to disable the cache altogether (drop the feature-cache option) and the problem disappears. If you do use it, clear the cache and run the script again:
rm -rf ../angie-feature-cache/
./configure ...
This time more checks pass, but an error is still likely. The build needs a set of libraries, and they must be installed in their development versions (the -dev suffix on Debian distributions, -devel on RedHat). The list of libraries depends on the module set being built. In this example (Ubuntu 26.04), a build with the options from the package fails because the PCRE library is missing (it is required for the rewrite module). The error looks like this:
...
checking for PCRE2 library ... not found
checking for PCRE library ... not found
checking for PCRE library in /usr/local/ ... not found
checking for PCRE library in /usr/include/pcre/ ... not found
checking for PCRE library in /usr/pkg/ ... not found
checking for PCRE library in /opt/local/ ... not found
checking for PCRE library in /opt/homebrew/ ... not found
./configure: error: the HTTP rewrite module requires the PCRE library.
You can either disable the module by using --without-http_rewrite_module
option, or install the PCRE library into the system, or build the PCRE library
statically from the source with Angie by using --with-pcre=<path> option.
Two options solve this: install the -dev package of the library, or build the library statically into Angie from source (pass --with-pcre=<path> pointing at the library sources).
Here is a quick detour into dynamic and static linking. Dynamic linking means referencing the paths of external libraries and sharing them with other software. For this method the library must be installed on the system and live in one of the standard directories (/usr/lib, /usr/lib64, and so on).
Static linking means integrating libraries into the angie executable. The library code is compiled while the server is built, and the dependency on system libraries goes away. The executable ends up larger in size, but with fewer external dependencies.
You can check an executable's dynamic links with the ldd utility:
ldd /usr/sbin/angie-nodebug
linux-vdso.so.1 (0x000075bf8008d000)
libcrypt.so.1 => /usr/lib/x86_64-linux-gnu/libcrypt.so.1 (0x000075bf8003b000)
libm.so.6 => /usr/lib/x86_64-linux-gnu/libm.so.6 (0x000075bf7ff15000)
libpcre2-8.so.0 => /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x000075bf7fb54000)
libssl.so.3 => /usr/lib/x86_64-linux-gnu/libssl.so.3 (0x000075bf7fa46000)
libcrypto.so.3 => /usr/lib/x86_64-linux-gnu/libcrypto.so.3 (0x000075bf7f400000)
libz.so.1 => /usr/lib/x86_64-linux-gnu/libz.so.1 (0x000075bf7fef5000)
libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x000075bf7f000000)
/lib64/ld-linux-x86-64.so.2 (0x000075bf8008f000)
libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 (0x000075bf7f33d000)
The command showed the list of libraries Angie can use, along with their paths in the filesystem. For comparison, the output of the same command on the angie binary with statically linked OpenSSL:
ldd /usr/sbin/angie-401
linux-vdso.so.1 (0x000075f782b46000)
libcrypt.so.1 => /usr/lib/x86_64-linux-gnu/libcrypt.so.1 (0x000075f782af4000)
libm.so.6 => /usr/lib/x86_64-linux-gnu/libm.so.6 (0x000075f7829ce000)
libpcre2-8.so.0 => /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x000075f781f54000)
libz.so.1 => /usr/lib/x86_64-linux-gnu/libz.so.1 (0x000075f7829b0000)
libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x000075f781c00000)
/lib64/ld-linux-x86-64.so.2 (0x000075f782b48000)
This variant has no libssl.so.3 and libcrypto.so.3 libraries — they are part of the executable itself.
In the same way as libraries, Angie supports static and dynamic linking of server modules. With dynamic linking a module can be loaded with the load_module directive; with static linking it is always loaded and its code is included in the Angie executable. For modules that support dynamic linking, the configure script takes a value of dynamic, for example:
--with-http_image_filter_module=dynamic
The advantage of dynamic linking is that the module file (.so) can be moved to other compatible systems, and Angie's functionality can be extended without a full rebuild of the server.
Back to the configure error:
./configure: error: the HTTP rewrite module requires the PCRE library.
The simplest solution is to install the package for this library:
apt install libpcre2-dev
After that, remember to clean the angie-feature-cache directory (if you use it). Once a dependency is satisfied, a new missing-library error keeps appearing until you install everything that is required. The process is not the fastest: each round means finding the right package name, clearing caches, and running the configure script again.
There is a more convenient way to install the dependencies (at least the ones a standard build needs). Enable the source package repository (in this case deb-src) in addition to the regular Angie repository, and /etc/apt/sources.list.d/angie.list becomes:
deb https://download.angie.software/angie/ubuntu/26.04 resolute main
deb-src https://download.angie.software/angie/ubuntu/26.04 resolute main
Now update the package list and install all build dependencies with one command:
apt update
apt build-dep angie
All the libraries needed to build the package are now installed. Extra third-party modules may of course introduce new dependencies.
So the preparation for the build is done. Here are a few real examples of building custom Angie versions.
Building with an alternative TLS library
The standard Angie packages from the official repository use dynamic linking for the system OpenSSL library. The simplest way to build Angie with a different library is static linking against OpenSSL. Download the library source from the official site (this example uses OpenSSL 4.0.1) and unpack it in a directory next to the Angie sources. Keep in mind that the current Angie version may be incompatible with the OpenSSL version you choose. Work on OpenSSL compatibility is usually announced in the server changelog.
wget https://github.com/openssl/openssl/releases/download/openssl-4.0.1/openssl-4.0.1.tar.gz
tar -xpf openssl-4.0.1.tar.gz
For static linking it is enough to add the --with-openssl=path option to the configure script, with the path to the OpenSSL sources.
If the configure script succeeds, start the build (the -j option sets the number of threads to use several processor cores):
make -j4
The build output lands in the ./objs directory, including the angie executable itself.
A more involved scenario uses one of the OpenSSL forks, AWS-LC. The build starts with preparing and building the library itself, and then it is passed to the configure script. This example uses AWS-LC 5.0.0 from the official GitHub repository:
wget https://github.com/aws/aws-lc/archive/refs/tags/v5.0.0.tar.gz
tar -xpf v5.0.0.tar.gz
Install the tools needed to build the library:
apt install golang-go cmake ninja-build
Move into the library directory and build it:
cd aws-lc-5.0.0/
cmake -GNinja -B build -DCMAKE_BUILD_TYPE=Release
ninja -C build
After a successful build, return to the Angie source directory and add these configure options:
--with-cc-opt='-fPIC -I ../aws-lc-5.0.0/include' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -Wl,-rpath -L ../aws-lc-5.0.0/build/ssl -L ../aws-lc-5.0.0/build/crypto -lssl -lcrypto -lstdc++'
Note that the --with-openssl option is not used here. Instead, compiler (--with-cc-opt) and linker (--with-ld-opt) options carry the paths for finding the AWS-LC library.
After the build (make), check the executable:
./objs/angie -V
Angie version: Angie/1.11.7
nginx version: nginx/1.29.3
built on Thu, 18 Jun 2026 12:59:32 GMT
built by gcc 15.2.0 (Ubuntu 15.2.0-16ubuntu1)
built with OpenSSL 1.1.1 (compatible; AWS-LC 5.0.0) (running with AWS-LC 5.0.0)
The use of the AWS-LC library is reflected in the command output.
Building Angie with a third-party module
For a third-party module example, this article uses the ngx_brotli project — a module for Brotli compression support. The build process is similar to the AWS-LC example.
Get the module source and build the required components following the instructions in README.md:
git clone --recurse-submodules -j8 https://github.com/google/ngx_brotli
cd ngx_brotli/deps/brotli
mkdir out && cd out
cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=OFF -DCMAKE_C_FLAGS="-Ofast -m64 -march=native -mtune=native -flto -funroll-loops -ffunction-sections -fdata-sections -Wl,--gc-sections" -DCMAKE_CXX_FLAGS="-Ofast -m64 -march=native -mtune=native -flto -funroll-loops -ffunction-sections -fdata-sections -Wl,--gc-sections" -DCMAKE_INSTALL_PREFIX=./installed ..
cmake --build . --config Release --target brotlienc
cd ../../../..
Now add an option to the configure script: --add-module=../ngx_brotli. This variant corresponds to static linking of the module. For dynamic linking use --add-dynamic-module=../ngx_brotli. Once the configure script succeeds, start the build (make).
If the build finishes successfully, it is time to move on to installation.
Installing build results and building packages
Managing software built from source is not the most pleasant task. Once the files are installed (copied into various directories of the filesystem), the system keeps no record of the software version, all of its files, or the other metadata contained in a package. Updates and removal become much harder.
Even so, a basic install of Angie after compilation takes one command:
make install
Keep in mind that a source build will not have some of the usual elements of a package. For example, the systemd unit for the service has to be created by hand. One option is to install Angie from a package and then install the custom version over it. In that case the Angie package version has to be held so the custom install is not overwritten:
apt-mark hold angie
The second installation option uses the checkinstall utility. It performs essentially the same actions as make install, but packs the files into a .deb package that can be installed on another system.
checkinstall --pkgname=angie-custom --pkgversion=1.11.8 --nodoc
This approach produces a package, but it is still an incomplete one. The resulting package can also be installed over the regular Angie package, followed by a version hold.
To get a complete independent package, use the Angie source package (from the deb-src repository), modify its configuration, and build it with the standard tooling. Keep in mind that a large number of third-party modules are built together with the standard Angie package.
Preparation: download the source packages and install the dependencies:
apt source angie
apt build-dep angie
Modify the configuration options in the ./debian/rules file.
Start the package build:
dpkg-buildpackage -b
This approach is more correct, since you get a self-contained set of packages with all the required components.
Summary
This article covered some aspects of building the Angie server from source. The process is not the simplest, but in some cases there is no other choice. On the other hand, the ability to build Angie opens a wide field for experiments. The commands and options are given for the software versions current at the time of writing. They may change in the future. The development team works on compatibility between components — watch the changelog.