Angie: a drop-in nginx replacement with its own HTTP/3, ACME and balancing work

What Angie is for, and who should care

Angie is a web server forked from nginx. The README states the goal plainly: it was forked "to act as a drop-in replacement, so you can use existing setups without major changes to module layout or configuration." The project was conceived by former members of the original nginx team. That framing sets the audience. Angie is for people who already have nginx configuration files, upstream blocks, stream blocks and mail proxy blocks, and who want to keep them rather than rewrite them for a different server.

The repository describes itself as building on the capabilities of nginx 1.31.2 and adding its own features on top. Those additions are not cosmetic. Production-ready HTTP/3 is listed for both client and proxied server connections, with the ability to use different protocol versions on opposite sides of a proxy. The README contrasts this with nginx, which it says limits HTTP/3 to the server side and keeps it experimental. That is a claim from the project about a competing implementation, not an independent measurement, and it should be read as such.

If you run a handful of nginx sites behind a load balancer and nothing about your setup is unusual, Angie's value proposition is mostly the configuration compatibility plus whatever new directives you decide to use. If you are pushing against nginx's limits in TLS automation, upstream selection or observability, the added modules are the reason to look.

How Angie is put together: nginx's core, new modules

The repository layout will look familiar to anyone who has built nginx. There is a configure script at the top level, an auto/ directory holding the build system, conf/ with default configuration, src/ with the C sources, html/ with default content, man/ with manual pages, and tests/. A CHANGES file and a CHANGES.ru file sit alongside LICENSE and README.rst. Nothing in this layout signals a rearchitected server. Angie inherits nginx's process model and configuration parser, and the fork's work lives in the modules and directives layered onto that core.

That inheritance is the mechanism behind the drop-in claim. Configuration is still read from a file, still parsed into the same directive tree, and still applied by worker processes. The new capabilities arrive as additional modules: http_v3 for HTTP/3, http_doh for a DNS over HTTPS server implementing RFC 8484, http_docker for updating upstream groups from Docker container events and labels, http_api for a RESTful interface exposing configuration and metrics, and stream-side modules for MQTT and RDP.

The interesting architectural choice is in the upstream logic. The README describes load balancing based on average response time using a probability-based selection algorithm. Faster servers attract proportionally more traffic, a configurable smoothing factor suppresses spikes, and no server is starved. The README argues manual weights are not needed because distribution follows measured response times, and states that nginx's approach is effectively least_conn with a time-based adjustment rather than a true response-time-aware algorithm. Whether that distinction matters depends on your workload, but it is a real difference in selection strategy rather than a renamed directive.

Installing Angie and serving a first site

The README does not contain installation commands. It points to the official documentation, which has installation pages in English, Russian, Chinese, Spanish and Portuguese. If you want packages, that installation page is where to look, and the README gives no package names, repository URLs or versions, so do not assume any from this article.

What the repository does give you is a source tree with a configure script and an auto/ directory, which is the nginx build convention. A source build therefore starts the way an nginx source build starts. The README mentions one build-time gate explicitly: support for NTLS when using the Tongsuo TLS library is enabled at build time, and the documentation link for that is under installation/sourcebuild. That tells you some features are compile-time decisions, not runtime toggles.

The repository does not include a minimal server block example, so the first real use is best taken from the runtime configuration documentation, which the README links under configuration. That page, not this article, is where the directive syntax and context rules for a first server block should be read, because the README itself carries no configuration snippet to copy.

HTTP/3, ACME and the TLS surface

The most concrete differentiators are in TLS and protocol handling. HTTP/3 is described as production-ready for client and proxied server connections, with independent protocol versions on each side. The HTTP/3 module is documented under http_v3, and the proxy side has a proxy_http_version setting. The README also points to an article about HTTP/3 degradation after reloads, which is a specific operational concern rather than a general performance claim.

Automatic HTTPS is handled by a built-in ACME implementation with HTTP, DNS and ALPN challenge support, plus ACME profiles and External Account Binding for commercial certificate authorities. That means certificate issuance and renewal do not require an external client or a cron job calling one. The documentation for it lives under the ACME configuration page, and the README does not describe failure handling when a challenge cannot be completed, so the renewal failure path is something to read up on rather than assume.

TLS 1.3 Early Data, or 0-RTT, is listed for both HTTP and stream modules. The README states nginx supports it only for HTTP. Server-side and client-side NTLS are available when building against the Tongsuo library, gated at build time. That last point matters: if you build with the default TLS library, NTLS is simply not in the binary, and no configuration directive will turn it on.

Where Angie is the wrong tool

The drop-in claim has a boundary, and the README draws it in its own wording: existing setups work "without major changes to module layout or configuration." Modules that are not part of Angie's tree are the obvious gap. A commercial or third-party nginx module that hooks into nginx internals has no guarantee of compiling or loading against a fork, and the repository does not provide a compatibility list. If your deployment depends on such a module, that dependency is the first thing to test, not the last.

Some features are build-time decisions. NTLS requires building with the Tongsuo TLS library. That means a binary from one source may not have a capability that a binary from another source does, and configuration documentation alone will not tell you which binary you are holding.

The README is also silent on several operational topics. It does not document rollback of a configuration change, it does not describe how the ACME implementation behaves when a challenge fails repeatedly, and it does not give a migration checklist. The troubleshooting page is linked, which suggests those answers exist in the documentation rather than the README, but the repository itself does not carry them. If your team needs a written rollback procedure before changing a production web server, that procedure is not in this repository.

Finally, if your requirement is a stable, frozen server you never touch, Angie's advantage is wasted. The value is in the added modules, and added modules mean new configuration surface to learn and test.

Angie compared with nginx and with the nginx ecosystem

The honest comparison is with nginx itself, because Angie is a fork of it and tracks nginx 1.31.2 as its base. The differences the README claims are specific: HTTP/3 on both client and proxied server sides versus server-side only and experimental; 0-RTT for stream as well as HTTP; session binding for stream upstreams as well as HTTP; slow_start for stream as well as HTTP; a response-time-based balancing algorithm rather than a least_conn variant; built-in ACME; a DoH server module; Docker-driven upstream updates without reload; and a RESTful API exposing configuration and metrics.

Those are all additive. Nothing in the README suggests Angie removed nginx behavior, and the drop-in framing depends on that. So the decision is not "which server is better" in the abstract. It is whether the specific additions match a gap you have. If you have never needed 0-RTT on a TCP stream, that line item is irrelevant to you. If you are running a mail proxy and want XOAUTH2 or OAUTHBEARER authentication, the README lists those as mail proxy additions and they may be exactly the gap.

Against other nginx-derived servers, the README does not make comparisons, so there is nothing here to report. Treat any claim about how Angie performs relative to another fork as unverified until you find a source that measured it.

Maintenance, licensing and what an upgrade costs

The repository is not archived. The last push was on 2026-09-26, and releases have been frequent: Angie 1.12.0 on 2026-07-14, 1.12.1 on 2026-07-17, and 1.12.2 on 2026-09-18. That cadence suggests active work, and the CHANGES file in the repository root is where the per-release detail lives.

The licence is BSD-2-Clause. That is a permissive licence, and it is the same family of licence nginx uses, which matters for the drop-in story: adopting Angie does not change the licensing posture of a deployment that was already running nginx under a permissive licence. This is a description of the licence identifier, not legal advice. If your organisation has specific obligations around attribution or redistribution, have counsel read LICENSE rather than this article.

Upgrade cost is where the fork model shows its shape. Because Angie tracks an nginx base, upgrades carry both Angie's own changes and whatever the upstream base brought in. The CHANGES file is the place to read before upgrading, and the tests/ directory in the repository shows the project maintains a test suite, though the README does not describe how to run it. If you build from source, remember that build-time features such as NTLS depend on your build configuration, so an upgrade that changes build flags can change what your binary supports.

Editorial conclusion

Adopt Angie if you already run nginx configuration and want HTTP/3 on both the client and proxied sides, ACME certificate provisioning, or upstream balancing driven by measured response time, and if you can build from source when a feature such as NTLS is gated behind build flags. Do not adopt it if you depend on nginx modules that are not part of the tree, or if you need a vendor support contract that the README does not describe. Before migrating, verify your own configuration against the runtime configuration documentation and confirm which features your build actually enables.

Frequently asked questions

Official sources

1. License: BSD-2-Clause
2. Project website
3. README
4. Releases
5. webserver-llc/angie on GitHub