If you ran nginx on Debian or Ubuntu with modules like brotli, geoip2, or headers-more, there's a good chance you got them from Ondřej Surý's apt repository. That repository is gone. Fully removed. And the landscape for nginx modules on these distros looks pretty different than it did a year ago.
Here's what happened, what your options are now, and what we did about it.
What Sury's repo was (and why it mattered)
Ondřej Surý maintained an apt repository that shipped nginx with prebuilt dynamic modules for Debian and Ubuntu. If you needed brotli compression, GeoIP2 lookups, or the headers-more module, you added his repo, ran apt install, and moved on with your life.
No compilation. No chasing build dependencies. No praying that your module still works after the next nginx update.
For a lot of sysadmins and dev teams, that repo was invisible infrastructure. It just worked, for years.
What happened
The mainline repository was the first to go, retired in summer 2025. Ondřej's stated reason was straightforward: packaging nginx with all the external modules is a major hassle for every upstream release. Every patch release means rebuilding modules against the new ABI, and the nginx-mainline repo wasn't actually getting that much usage according to his download stats.
Fair enough. Maintaining something like that for the community with no funding or institutional backing is a thankless job.
Then in January 2026, he announced the stable repository would follow. By April 2026, it was fully removed. The packages, the signing keys, the source lists, all of it. Gone.
If you still have sury-nginx.list sitting in /etc/apt/sources.list.d/, it's pointing at nothing.
Where that leaves you
You now have roughly four options for nginx modules on Debian and Ubuntu. None of them are perfect, but some are significantly less painful than others.
Option 1: The distro packages
Debian and Ubuntu ship their own nginx packages. Debian offers nginx-core, nginx-full, and nginx-extras variants with different module sets baked in. Ubuntu's default repos do something similar.
The problem? These are statically compiled bundles. You get whatever modules Debian or Ubuntu decided to include, and nothing else. Want brotli? Not in there. Want zstd? No. Want to mix and match? Can't.
Oh, and Ubuntu 22.04 LTS still ships nginx 1.18. That's from 2020. You're running a web server with a version number old enough to start school.
Option 2: The nginx.org official repo
Nginx.org maintains their own apt repository with current stable and mainline releases. This is what you should be running if you care about security patches and performance improvements.
They also ship a handful of dynamic modules: njs, image-filter, perl, xslt, and the newer otel and acme modules. These cover some use cases. But they don't ship brotli, geoip2, headers-more, modsecurity, zstd, or most of the modules that Sury's repo made easy to install.
Option 3: Compile everything yourself
This is the option that technically always exists and practically always hurts.
The process goes something like this:
- Install build-essential, libpcre2-dev, zlib1g-dev, libssl-dev, and whatever other dependencies your specific module needs
- Download the exact nginx source that matches your installed version (get the version wrong and the module won't load)
- Clone the module source from GitHub
- Run
./configurewith the right flags - Run
make modules - Copy the
.sofile to the right place - Cross your fingers
Then nginx releases a patch version. Your module was compiled against 1.28.0, but now you're on 1.28.1. The ABI changed. The module won't load. Start over from step 2.
Every single nginx update becomes a maintenance task. If you have three or four modules, you're rebuilding all of them. If you're managing more than a couple of servers, you're either building packages yourself (congratulations, you're now a package maintainer) or running Ansible playbooks that shell out to make. Neither option sparks joy.
We've seen clients spend hours debugging module load failures that came down to a minor version mismatch between the compiled module and the running nginx binary. It's not hard to fix once you know what's wrong. But it's time you shouldn't have to spend.
Option 4: A prebuilt module repository
If you're on RHEL or CentOS, GetPageSpeed has been doing prebuilt nginx modules since 2016 and launched apt support in early 2026. They have a large module catalog and tiered subscription plans. If you need 100+ modules or are in the RPM ecosystem, they're worth a look.
We built something different. After Sury announced the stable repository retirement, we looked at our own infrastructure and realized we had the same problem everyone else was about to have. We run brotli, geoip2, headers-more, and a few other modules across our production servers. Compiling them ourselves every time nginx releases an update wasn't going to work.
So we built nginx-modules.com: an apt repository with 11 prebuilt dynamic modules, packaged for Debian and Ubuntu, built against official nginx.org stable releases, and updated within 24 hours of every new nginx version. Free, no subscription tiers, fully open build pipeline on GitHub. We ship the modules we actually run in production, not a catalog of everything that compiles.
What's in the repository
Eleven modules, all packaged as standard .deb files:
Compression:
nginx-module-brotli- On-the-fly brotli compressionnginx-module-brotli-static- Serve pre-compressed.brfilesnginx-module-zstd- Zstandard compression (Meta's algorithm, faster decompression than brotli)
Security:
nginx-module-modsecurity- ModSecurity WAF connector
Geolocation:
nginx-module-geoip2- MaxMind GeoIP2 lookups for HTTPnginx-module-stream-geoip2- GeoIP2 for TCP/UDP streams
Headers & Content:
nginx-module-headers-more- Full control over request and response headersnginx-module-substitutions- Regex find-and-replace in response bodies
Caching:
nginx-module-cache-purge- Selective cache entry invalidation
Utility:
nginx-module-fancyindex- Directory listings that don't look like 1994nginx-module-dav-ext- WebDAV methods that nginx left out (PROPFIND, LOCK, UNLOCK)
Supported distros: Debian Bookworm, Debian Trixie, Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, and Ubuntu 26.04 LTS. Both amd64 and arm64.
How the builds work
Every package is compiled on public GitHub Actions. The build pipeline, the packaging scripts, the signing process, it's all in the open on GitHub. You can read every step, reproduce any build, and verify the output yourself.
We don't run proprietary build servers. We don't have opaque signing ceremonies. If something looks off, open an issue.
Packages include ABI version constraints, so apt won't let you install a module built for one nginx version on a different one. When nginx releases a new stable version, rebuilt modules are typically available within 24 hours. Run apt upgrade and everything stays in sync.
Getting started
If you're already running nginx from nginx.org (you should be), setup is five lines:
sudo install -d -m 0755 /etc/apt/keyrings
curl -fsSL https://apt.blendbyte.net/nginx/blendbyte-archive-keyring.gpg \
| sudo tee /etc/apt/keyrings/blendbyte.gpg >/dev/null
echo "deb [signed-by=/etc/apt/keyrings/blendbyte.gpg] https://apt.blendbyte.net/nginx $(lsb_release -cs) main" \
| sudo tee /etc/apt/sources.list.d/blendbyte.list
sudo apt update
Then install whatever you need:
sudo apt install nginx-module-brotli nginx-module-geoip2 nginx-module-headers-more
That's it. No compiling, no build dependencies, no version matching. Modules auto-enable on install.
Migrating from Sury
If you're coming from Sury's repo specifically, the package swap is one apt transaction. Our packages declare Replaces and Conflicts against the old libnginx-mod-* package names, so apt handles the rename automatically.
One thing to know: Sury supported up to nginx 1.28, and our packages start at nginx 1.30. So nginx itself will upgrade and restart during the migration. Review your config before you run it.
# Remove Sury's source (if you use Sury for PHP too, only remove the nginx file)
sudo rm -f /etc/apt/sources.list.d/sury-nginx.list
# Add Blendbyte
sudo install -d -m 0755 /etc/apt/keyrings
curl -fsSL https://apt.blendbyte.net/nginx/blendbyte-archive-keyring.gpg \
| sudo tee /etc/apt/keyrings/blendbyte.gpg >/dev/null
echo "deb [signed-by=/etc/apt/keyrings/blendbyte.gpg] https://apt.blendbyte.net/nginx $(lsb_release -cs) main" \
| sudo tee /etc/apt/sources.list.d/blendbyte.list
sudo apt update && sudo apt upgrade
Verify with sudo nginx -t && sudo systemctl reload nginx. If nginx reports success, you're done.
The full migration guide with module mapping and edge cases is at nginx-modules.com/migrate-from-sury.
What we don't ship (and why)
We're not trying to be a module supermarket. We ship what we run in production. If it's not on the list, either we don't use it, or there's a better answer:
- Lua/NDK: Use OpenResty. Bolting the Lua module onto stock nginx is asking for trouble.
- GeoIP v1: MaxMind killed those databases in 2018. Use GeoIP2.
- PageSpeed: Google archived it in 2020. Let it rest.
- njs, otel, image-filter, perl, xslt: Already available from the nginx.org repo. Get them there.
Need a module we don't have? Open an issue on GitHub with a maintainer attached. We only add modules that someone commits to maintaining. Requests without a maintainer close without action. It's a small project and that's how it stays manageable.
The bigger picture
The Sury shutdown exposed something that's been true for a long time: the nginx module ecosystem on Debian and Ubuntu has always been fragile. It's relied on individual maintainers doing unpaid work, distro packages that lag years behind, and an official repository that covers the basics but not much else.
For a web server that powers a huge chunk of the internet, that's not great.
We don't pretend to have solved this for everyone. We built what we needed, packaged it properly, and opened it up. It's free, it's open source, and it'll stay that way because we use it ourselves.
Need help with your nginx setup?
We built nginx-modules.com because we run this stuff for clients every day. If you need help with nginx configuration, module selection, performance tuning, or migrating from another setup, that's what we do.
Talk to us. First 30 minutes are free, and you'll talk to the engineers, not a sales team.
