Angie Web Server: The Complete Guide — Review, ACME, Migration, API and HTTP/3

In 2021, a group of engineers left F5 Networks — the company that had acquired NGINX Inc. in 2019. These weren’t peripheral contributors. They were the original NGINX core team: the people who wrote the event loop, designed the memory allocator, built the module system. They left because F5’s roadmap for NGINX was, diplomatically, not their vision. They forked the codebase and called it Angie.

That origin story matters. Angie isn’t a community fork with sporadic commits. It’s the continuation of NGINX development by the people who invented it, without corporate constraints. The result is a web server that is 100% backward-compatible with NGINX — every config file, every directive, every module works unchanged — but with features that F5 was either charging for (NGINX Plus) or not building at all.

This guide covers everything about Angie in one place: what it is, what it adds, how it performs, how to migrate from NGINX, how to set up native ACME certificates, how to use the monitoring API, and how to decide whether it’s right for you. The myguard APT repository ships Angie for Debian and Ubuntu with all 50+ dynamic modules pre-built.

What Angie adds over NGINX — the full list

These are the capabilities Angie has that stock NGINX mainline does not:

1. Native ACME client (Let’s Encrypt without Certbot)

This is the headline feature and the one that earns Angie the most converts. Angie has a full RFC 8555 ACME client built directly into the server. You declare certificates in angie.conf, Angie fetches them on first start, and renews them automatically before expiry. No Certbot. No cron jobs. No renewal hooks. No 2am emergency when a certificate silently expires.

http {
    acme_client letsencrypt https://acme-v02.api.letsencrypt.org/directory
        email admin@example.com;

    server {
        listen 443 ssl;
        http2 on;
        server_name example.com www.example.com;

        acme letsencrypt;
        ssl_certificate      $acme_cert_letsencrypt;
        ssl_certificate_key  $acme_cert_key_letsencrypt;
    }
}

Reload Angie and the certificate is issued within seconds. Zero-downtime renewal happens automatically when fewer than 30 days remain. Multiple CAs are supported simultaneously — Let’s Encrypt and ZeroSSL in parallel, private internal CAs, staging environments.

2. JSON status API with Prometheus endpoint

NGINX’s built-in stub_status module returns five lines of plain text. Angie’s status API returns structured JSON with detailed per-server, per-upstream, and per-connection metrics. Add it to any server block:

location /status {
    api /status/;
    allow 127.0.0.1;
    deny all;
}

location /metrics {
    api /metrics/prometheus;
    allow 127.0.0.1;
    deny all;
}

The /metrics/prometheus endpoint returns Prometheus-format metrics — no third-party exporter needed. Plug it straight into your Grafana dashboard. The JSON API includes: active connections, requests/sec per server, upstream server health, SSL certificate expiry dates, response time percentiles, and bytes transferred.

3. Dynamic upstream management (NGINX Plus feature, free in Angie)

NGINX requires a full reload to add or remove upstream servers. NGINX Plus offers dynamic upstreams via its paid API. Angie offers this for free via its status API:

# Add an upstream server without reloading
curl -X POST http://127.0.0.1/status/upstreams/backend/servers 
  -H 'Content-Type: application/json' 
  -d '{"server": "192.168.1.100:8080"}'

This is enormous for Kubernetes and container deployments where backend IPs change constantly. No reload means no brief traffic interruption during scaling events.

4. Monthly release cadence

NGINX mainline releases every three to four months. Angie releases roughly monthly. Security fixes ship faster. New features accumulate faster. The gap compounds over time.

5. Extended upstream health checks

Angie’s active health checks are more configurable than NGINX’s — check HTTP status codes, match response body patterns, set custom failure thresholds — all without a commercial licence. NGINX Pro/Plus features, available free.

6. HTTP/3 and QUIC

Same as the myguard NGINX build — full HTTP/3 support via openssl-nginx with QUIC patches. The configuration is identical to NGINX’s HTTP/3 setup.

Performance: Angie vs NGINX

The honest answer: essentially identical. Angie and NGINX share the same core architecture — event-driven, asynchronous, single-threaded workers managing thousands of connections each. The performance comes from the design, not from either project’s additions on top of it.

Tested with wrk on 4 vCPU/8GB, 1KB static file, both compiled with the same optimization flags via the myguard build system. Differences are within noise margin.

For PHP and proxy workloads the comparison is the same — the bottleneck is PHP-FPM or the upstream app, not the web server. Pick based on features, not benchmarks.

Who should use Angie

Start with Angie if you’re setting up a new server

For fresh deployments in 2026, Angie is the better default. Native ACME removes Certbot as a dependency. The JSON API means you get monitoring without installing a separate exporter. The monthly release cycle means security patches arrive faster. There’s no reason to start with NGINX and then add the complexity of Certbot when Angie handles it natively.

Migrate from NGINX if you value simplicity

If you’re currently running Certbot renewal timers, a stub_status scraper, and three shell scripts to manage certificate hooks — Angie replaces all of that with directives in angie.conf. The migration is five minutes and your config works unchanged.

Stay on NGINX if you need these specific things

• You use a module that hasn’t been ported to Angie yet (check the Angie modules page — most are available)
• You have a specific vendor integration that hard-requires NGINX (rare but exists in enterprise)
• Your organisation mandates specific software and hasn’t approved Angie yet

In all other cases, Angie is a strict improvement on NGINX for new deployments.

Installation

wget https://deb.myguard.nl/pool/myguard.deb
dpkg -i myguard.deb
apt-get update
apt-get install angie

Supported distributions: Debian 12 (Bookworm), Debian 13 (Trixie), Ubuntu 22.04 (Jammy), Ubuntu 24.04 (Noble), Ubuntu 26.04 (Resolute). Both amd64 and arm64.

All 50+ dynamic modules are available as angie-module-* packages and load with load_module in angie.conf:

apt-get install angie-module-http-brotli angie-module-http-modsecurity angie-module-http-geoip2

Migrating from NGINX to Angie

This is the easiest server migration you will ever do. Your config files work without changes. Your modules have 1:1 equivalents. Your sites stay online throughout.

Step 1 — Back up your config

tar -czf /tmp/nginx-backup-$(date +%Y%m%d).tar.gz /etc/nginx/
nginx -V 2>&1 | grep -o 'modules/[^ ]*.so'   # note which modules you use

Step 2 — Add the myguard repository and install Angie

wget https://deb.myguard.nl/pool/myguard.deb
dpkg -i myguard.deb
apt-get update
apt-get install angie

Angie installs alongside NGINX without removing it. They coexist as packages — they just can’t both listen on ports 80 and 443 at the same time.

Step 3 — Test your config with Angie

angie -t
# Angie reads /etc/nginx/ by default
# "syntax is ok" means you're ready to switch

Step 4 — Switch over

systemctl stop nginx
systemctl start angie
systemctl status angie

Step 5 — Verify your sites

curl -I https://yourdomain.com
tail -f /var/log/angie/error.log

Step 6 — Make it permanent

systemctl disable nginx
systemctl enable angie

Rollback (if needed)

systemctl stop angie
systemctl start nginx
# NGINX config is untouched, sites are back online

Module package name mapping

ACME / Let’s Encrypt: full configuration guide

Basic single domain

http {
    acme_client letsencrypt https://acme-v02.api.letsencrypt.org/directory
        email admin@example.com;

    # HTTP → HTTPS redirect
    server {
        listen 80;
        server_name example.com www.example.com;
        return 301 https://$host$request_uri;
    }

    server {
        listen 443 ssl;
        listen 443 quic reuseport;  # HTTP/3
        http2 on;
        http3 on;
        server_name example.com www.example.com;

        acme letsencrypt;
        ssl_certificate      $acme_cert_letsencrypt;
        ssl_certificate_key  $acme_cert_key_letsencrypt;

        ssl_protocols       TLSv1.2 TLSv1.3;
        ssl_session_cache   shared:SSL:10m;
        ssl_session_timeout 1d;
        ssl_session_tickets off;

        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
        add_header Alt-Svc 'h3=":443"; ma=86400';
    }
}

Multiple certificate authorities

acme_client letsencrypt https://acme-v02.api.letsencrypt.org/directory;
acme_client zerossl    https://acme.zerossl.com/v2/DV90;

server {
    acme letsencrypt;
    acme zerossl;
    ssl_certificate      $acme_cert_letsencrypt;
    ssl_certificate_key  $acme_cert_key_letsencrypt;
}

Private / internal CA

acme_client internal https://ca.internal/acme/directory;
# Works with Step CA, HashiCorp Vault PKI, EJBCA, Smallstep

Staging for testing (avoids rate limits)

acme_client staging https://acme-staging-v02.api.letsencrypt.org/directory;

Custom certificate storage path

acme_client letsencrypt https://acme-v02.api.letsencrypt.org/directory
    email admin@example.com
    path /etc/angie/ssl/acme;

How ACME renewal works

Let’s Encrypt certificates expire after 90 days. Angie starts renewal when fewer than 30 days remain, giving a 60-day buffer. Renewal uses a graceful reload — active connections finish with the old certificate, new connections use the new one. Zero downtime, zero cron jobs.

ACME uses HTTP-01 challenges — port 80 must be reachable from the internet. Wildcard certificates (*.example.com) require DNS-01 challenges which Angie’s built-in ACME doesn’t support; use Certbot with a DNS plugin for those specific cases.

Migrating from Certbot to Angie ACME

# 1. Add acme_client and acme directives to your config
# 2. Change ssl_certificate paths to $acme_cert_* variables
# 3. Test: angie -t
# 4. Reload: systemctl reload angie (fetches certificate immediately)
# 5. Confirm: openssl s_client -connect example.com:443 2>/dev/null | grep -A1 'Certificate chain'
# 6. Remove certbot: apt-get remove certbot
#    (delete any renewal timers and hooks)

Monitoring: JSON API and Prometheus

Angie’s status API is a REST endpoint that returns real-time server metrics. It’s available for both JSON consumption and Prometheus scraping — no extra software needed.

Enable the API

server {
    listen 127.0.0.1:8080;

    location /status {
        api /status/;
    }

    location /metrics {
        api /metrics/prometheus;
    }
}

Query it

# Full JSON status
curl -s http://127.0.0.1:8080/status | python3 -m json.tool

# Prometheus metrics for Grafana/Prometheus scraping
curl -s http://127.0.0.1:8080/metrics

# Just connection counts
curl -s http://127.0.0.1:8080/status/connections

# Upstream health
curl -s http://127.0.0.1:8080/status/upstreams

# Certificate expiry
curl -s http://127.0.0.1:8080/status/ssl

Dynamic upstream management via API

# Add an upstream server (no reload required)
curl -X POST http://127.0.0.1:8080/status/upstreams/backend/servers 
  -H 'Content-Type: application/json' 
  -d '{"server": "192.168.1.100:8080", "weight": 1}'

# Remove a server
curl -X DELETE http://127.0.0.1:8080/status/upstreams/backend/servers/0

# Drain a server before removal (set to 'draining')
curl -X PATCH http://127.0.0.1:8080/status/upstreams/backend/servers/0 
  -H 'Content-Type: application/json' 
  -d '{"drain": true}'

Grafana dashboard

Point a Prometheus scrape config at http://127.0.0.1:8080/metrics. The metrics follow standard naming conventions and work with existing NGINX Prometheus dashboards (Grafana dashboard ID 12708 and similar).

HTTP/3 and QUIC with Angie

Angie’s HTTP/3 configuration is identical to NGINX’s. Both use the same openssl-nginx QUIC build. Add QUIC alongside your existing HTTPS listener:

server {
    listen 443 ssl;
    listen 443 quic reuseport;   # HTTP/3
    http2 on;
    http3 on;
    quic_retry on;

    ssl_protocols TLSv1.3;       # HTTP/3 requires TLS 1.3
    ssl_early_data on;

    add_header Alt-Svc 'h3=":443"; ma=86400';
    # ... rest of your server block
}

Open UDP 443 in your firewall (ufw allow 443/udp or the iptables/nftables equivalent) — QUIC runs on UDP. HTTP/3 falls back gracefully to HTTP/2 for clients that don’t support it. See the full HTTP/3 setup guide for verification steps and troubleshooting.

Angie vs NGINX Plus

NGINX Plus is NGINX’s commercial version, priced at ~$3,000/year per server. It adds the features that Angie provides for free:

For most organisations, Angie delivers the operational features of NGINX Plus without the licence fee.

Frequently asked questions

Related posts

• Angie modules overview — all 50+ dynamic modules available via APT, with descriptions and install commands
• openssl-nginx: Dedicated OpenSSL for NGINX and Angie — the TLS layer underneath, with kTLS, post-quantum crypto, and QUIC
• TLS Configuration: Get A+ on SSL Labs — complete TLS hardening guide for Angie and NGINX
• How to Enable HTTP/3 on NGINX (works identically on Angie) — step-by-step QUIC setup
• NGINX & Angie: Expert Guide to Performance and Security — full performance tuning and hardening
• How to add the myguard APT repository — two-minute setup for Debian and Ubuntu