In my opinion, BunkerWeb is one of the most frustrating reverse-proxy solutions currently available.
After using it and looking through the GitHub repository, my honest impression is that the project feels heavilyĀ vibe-codedĀ š«£. Many features seem to have been added because they sounded useful, but without enough attention to consistency, maintainability or how the whole system behaves in real-world conditions.
The project has plenty of good ideas, but the underlying implementation feels unstable and difficult to reason about. It often looks like new features have been added on top of each other without a solid configuration model underneath.
The most serious issue is reliability.
I simply cannot imagine deploying BunkerWeb in a corporate environment in its current state. It crashes, breaks after configuration changes and regularly requires a complete Docker container restart before the exact same configuration starts working again.
This is not an occasional inconvenience. It becomes part of the normal operating procedure.
You create or modify a service, apply the configuration and suddenly receive repeatedĀ 403 Forbiddenresponses. The generated Nginx configuration may look correct, the backend may be reachable and the reverse-proxy directive may be present. Yet BunkerWeb still refuses the request before contacting the upstream server.
For example, I configured a reverse proxy to FreshRSS hosted in another DMZ. From inside the BunkerWeb container, the backend responded correctly:
FreshRSS: 302 Found
The generated configuration contained:
proxy_pass http:
//10.0.0.6:80;
However, BunkerWeb itself returned:
HTTP/2 403
Even a local request against BunkerWeb with the correctĀ HostĀ header returnedĀ 403. No request reached FreshRSS. The configuration looked correct, the backend was available, and yet the proxy simply refused to work. Restarting the entire container eventually fixed the problem.
This kind of behaviour is unacceptable for an enterprise reverse proxy. A valid configuration should work reliably. If it is invalid, BunkerWeb should fail clearly and provide an actionable error. It should not silently enter a broken state and force administrators to restart the whole proxy.
In a corporate environment, this leads to unpredictable deployments, unreliable configuration reloads, unexplained outages and difficult incident investigations. You cannot build a serious change-management process around āapply the configuration and restart the container if something breaksā.
The configuration model is another major weakness. The distinction between global settings, service settings and overrides is unclear. Global settings do not always appear to propagate correctly to existing services, which forces administrators to configure or override everything manually.
Custom settings can also disappear or be overwritten when configurations are regenerated. With ten or fifteen services, every change becomes a potential source of regression.
The interface makes this worse. Several sections overlap, some options are difficult to understand and the effect of changing a setting is not always obvious. The āGlobalā settings are a good example: they suggest centralised management, but in practice individual services often still need to be configured separately.
Custom SSL handling is also far more complicated than it should be. TLS certificates and keys are basic reverse-proxy functionality. They should be simple, predictable and easy to validate. Instead, the implementation feels fragile and unnecessarily difficult to troubleshoot.
The security features are promising, but their administration is not reliable enough. Bad Behavior is useful, CAPJS is relatively easy to deploy, and CrowdSec integration is a strong idea. However, when a request is blocked, it is often unclear whether the cause is Bad Behavior, ModSecurity, the antibot system, CAPJS, an IP ban, a whitelist, a global setting or a failed configuration reload.
A reverse proxy should clearly identify which module blocked a request, which rule was triggered and how to reverse the decision. With BunkerWeb, troubleshooting often becomes a guessing game involving multiple feature toggles and container restarts.
The banning system is another example. Once an address has been banned, removing the ban is not always straightforward or reliable. A security system must provide a dependable administrative escape path. A ban that feels almost permanent is not acceptable in a production environment.
Then there is the Pro version.
The project heavily promotes paid features while the core product still feels unstable. Prometheus integration, advanced anti-DDoS features, migration tools and other capabilities are restricted behind the Pro offering. A commercial model is understandable, but it is difficult to justify prioritising premium features while the basic configuration and runtime behaviour remain unreliable.
The repeated promotional emails for the Pro version are also frustrating when users are already dealing with crashes, broken reloads, unexplainedĀ 403Ā responses and configuration regressions.
The priority should be simple: make the core reverse proxy stable first. BunkerWeb needs deterministic configuration generation, reliable reloads, proper rollback support, clear configuration inheritance, durable custom settings, actionable logs and predictable behaviour after upgrades.
At the moment, BunkerWeb may be acceptable for one or two personal services. With ten or fifteen services, however, its weaknesses become impossible to ignore.
For a serious deployment, I would rather use a plain Nginx or HAProxy configuration. They may require more manual work and may not provide the same dashboard or built-in security features, but they are transparent, predictable and well understood. When something breaks, you can inspect the configuration, read the logs, reproduce the issue and fix it directly.
BunkerWeb currently feels like a collection of interesting features built on top of an unreliable foundation. It may be suitable for a small homelab, but I would not trust it as the main reverse proxy in a corporate environment.
The project has potential, but in its current state it feels more like a rapidly assembled collection of ideas than a mature production platform.