BunkerWeb is a next-generation, open-source, cloud-native Web Application Firewall built as a full-featured web server on top of NGINX, designed to make web services secure by default, and it is aimed at teams running web services on Linux, Docker, Swarm, or Kubernetes who want protection in place as a reverse proxy rather than assembled by hand.

What it is

BunkerWeb is a Web Application Firewall that is also a complete web server. It sits in front of web services as a reverse proxy and applies a set of primary security features as part of its core, based on NGINX. It integrates into existing environments — Linux, Docker, Swarm, Kubernetes — so the deployment shape a team already runs is the shape BunkerWeb runs in. Configuration happens either through the command-line interface or through a web UI for those who prefer not to work at the CLI, and the core can be extended through a plugin system.

The concrete problem it solves is the gap between installing a web server and actually having a hardened one. Instead of an operator wiring TLS, headers, ModSecurity, rule sets, rate limits, and bot handling together by hand, BunkerWeb ships that as default behaviour. It replaces the manual assembly of NGINX plus ModSecurity and the hand-written configuration that usually accompanies it, and it also replaces the work of obtaining and renewing certificates manually. The project is written primarily in Python and is licensed under AGPL-3.0.

Key capabilities

• HTTPS support with transparent Let's Encrypt automation, so certificate issuance and renewal are handled rather than scripted.
• Integrated ModSecurity WAF with the OWASP Core Rule Set, giving a request-inspection layer out of the box.
• HTTP security headers, leak prevention, and TLS hardening applied as part of the default posture.
• Automatic ban of strange behaviour based on HTTP status codes returned by the protected service.
• Bot blocking through a challenge mechanism, with cookie, JavaScript, captcha, hCaptcha, or reCAPTCHA options.
• Connection and request limits applied per client to constrain abusive traffic.
• Blocking of known bad IPs using external blacklists and DNSBL lookups.
• A plugin system that extends the core with additional security features for specific use cases.

Who uses it and how

• DevOps and DevSecOps teams, which the project's own topics call out directly, using it as the security layer in front of services they deploy.
• Hosting providers and self-hosters running multiple web services behind a single reverse proxy, using the web UI rather than the CLI to manage configuration.
• Kubernetes operators, who deploy it into an existing cluster integration instead of introducing a separate edge stack.
• Docker and Swarm users, who add it to the environment they already run rather than rebuilding around a new one.
• Teams that want to enable, disable, and configure individual features per use case, since the security settings are tunable rather than fixed.

Getting started

Deployment follows the integration for the environment already in use — Linux, Docker, Swarm, or Kubernetes — as documented in the project's integrations section. When CLI configuration is not wanted, the web UI is the supported path to settings and configuration.

How it compares

Among the tools the project itself names, BunkerWeb bundles pieces that are normally separate: NGINX as the web server, ModSecurity with the OWASP Core Rule Set as the request inspection engine, and Let's Encrypt for certificates. An operator assembling those independently gets the same underlying components but owns the integration, the default configuration, and the ongoing maintenance of each part. Compatibility with those components is the point rather than a departure from them, with the difference being what ships pre-configured.

When to use it — and when not to

BunkerWeb suits teams that want a reverse proxy and a WAF in one deployable unit and are willing to adopt its configuration model, including the plugin system, to extend it. Teams that already run a mature NGINX and ModSecurity setup with their own automation may find the added layer redundant. The repository shows a healthy but not idle project — roughly 11,000 stars, 642 forks, and 170 open issues — and the README is promotional in tone, describing features and linking to documentation for specifics rather than laying out the installation commands directly, so the documentation site is the actual source of operational detail.

</a>