BunkerWeb: an NGINX-based open source WAF that ships secure by default

What BunkerWeb solves, and for whom

Most teams that want a web application firewall face the same setup cost: install ModSecurity, wire it into NGINX, fetch and tune the OWASP Core Rule Set, then keep that stack patched. BunkerWeb packages that work into a single component that is itself a full web server, based on NGINX. The README describes it as a next-generation, open-source Web Application Firewall and says it protects web services to make them secure by default. The audience is anyone running HTTP services behind a reverse proxy: Linux servers, Docker, Swarm, Kubernetes. The project also targets people who do not want to write NGINX configuration, since the README points to a web UI as an alternative to the CLI. That framing matters. BunkerWeb is not a library you embed in an application, and it is not a scanner that reports on traffic after the fact. It sits in the request path and decides what reaches your service.

How the NGINX, ModSecurity and plugin layers fit together

The architecture is a proxy with a rule engine inside it. BunkerWeb is based on NGINX, so requests terminate at BunkerWeb, pass through its security features, and are forwarded to the upstream service. The README lists an integrated ModSecurity WAF with the OWASP Core Rule Set as a core feature, which means the Core Rule Set runs inside that request path rather than in a separate appliance. Around that core sit features you can enable or disable: HTTPS with transparent Let's Encrypt automation, HTTP security headers, TLS hardening, automatic ban of strange behaviour based on HTTP status codes, connection and request limits for clients, and bot blocking that asks clients to solve a challenge such as a cookie. The plugin system is the extension point: the README says the core carries primary security features and that additional ones can be added through plugins. Configuration is the interesting part. The README says BunkerWeb is fully configurable and integrates into existing environments as a reverse proxy, and that the web UI exists for people who do not like the CLI.

Installing BunkerWeb: Linux, Docker, Swarm or Kubernetes

The README links integration guides for Linux, Docker, Swarm and Kubernetes on docs.bunkerweb.io, and the repository carries an examples/ directory with per-scenario folders such as examples/ghost/ and examples/drupal/ for common upstreams. If you are starting from nothing, read the integration guide for your platform first, then look at the examples/ folders that match your upstream. The README also links a hosted demo UI and describes the web UI as the alternative to the CLI.

Where BunkerWeb is the wrong tool

BunkerWeb is inline. Every request goes through it, so it inherits the failure modes of a proxy: if BunkerWeb is unhealthy or misconfigured, your service is unreachable rather than merely unprotected. Teams that need out-of-band detection, where a sensor watches a copy of the traffic and never touches the live path, are looking at a different category of product. The same applies to anyone who wants to unit-test WAF rules as code in a CI pipeline without standing up a proxy. There is a second constraint that the README states plainly: BunkerWeb is a full-featured web server based on NGINX. If you already run an NGINX configuration you maintain by hand, adopting BunkerWeb means either migrating that configuration into BunkerWeb's settings model or placing BunkerWeb in front of it, which adds a hop. Neither is free. And because the security features are on by default, a first deployment can produce false positives from the Core Rule Set against legitimate traffic. Plan to test tuning changes against a staging host before they reach production.

BunkerWeb compared with ModSecurity and CrowdSec

The most useful comparison is with the components BunkerWeb already contains. ModSecurity is a rule engine that you install into a web server and configure yourself; BunkerWeb embeds ModSecurity and the OWASP Core Rule Set and adds the surrounding operational layer, including certificate automation, client connection and request limits, bot challenges and a UI. If you want the rule engine alone and already have an NGINX configuration you trust, plain ModSecurity is less machinery. CrowdSec approaches the problem from the other direction. It is a behaviour-based detection engine that shares signals across installations; BunkerWeb's automatic ban feature, which the README describes as banning based on HTTP status codes, is a narrower in-proxy equivalent. The two are not mutually exclusive. On the deployment side, Traefik is a reverse proxy with middleware, not a WAF with a Core Rule Set, so teams comparing the two are really comparing a router with a security appliance that also routes.

Licence, releases and the cost of staying current

BunkerWeb is licensed under AGPL-3.0, and the README frames this as free as in freedom, with the freedom to use, modify and distribute the software. The practical implication for a company embedding BunkerWeb in a product is the network-copyleft clause that AGPL-3.0 carries; whether that affects your distribution model is a question for your own legal review, not something this article can settle. The README also lists professional services from the maintainers, including technical support and custom development, which is the usual commercial path around a copyleft core. On maintenance, the repository is not archived and the last push was on 2026-11-02, with v1.6.17 released on 2026-10-21 and v1.6.18-rc1 and v1.6.18-rc2 tagged on 2026-10-26 and 2026-10-30. That cadence has a cost: if you pin an image tag, you are choosing when to absorb rule and feature changes, and the Core Rule Set underneath moves on its own schedule. The pyproject.toml carries version 1.6.17, matching the latest stable release.

Editorial conclusion

Adopt BunkerWeb if your services already sit behind a reverse proxy and you want ModSecurity, the OWASP Core Rule Set, Let's Encrypt automation and client connection and request limits configured through BunkerWeb's settings or its web UI rather than hand-written NGINX files. Do not adopt it if you need an out-of-band detector that only observes traffic, or if your deployment cannot tolerate a proxy in the request path. Before rolling it out, verify the exact image tag you intend to pin, whether your team needs the web UI or can stay on the CLI, and how you will test Core Rule Set tuning against real traffic.

Frequently asked questions

Official sources

1. bunkerity/bunkerweb on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases