Exposing self-hosted web applications—such as Nextcloud, Jellyfin, or a personal blog—to the public internet requires more than just port forwarding. A basic forwarding-only reverse-proxy configuration does not include a web application firewall. A proxy can provide additional controls when they are deliberately configured. Today we look at BunkerWeb, an open-source, next-generation Web Application Firewall (WAF) and reverse proxy built on top of NGINX that brings application-layer filtering to your homelab.
What Is BunkerWeb?
BunkerWeb is a hardened, open-source web server and reverse proxy designed to make strong web security the default rather than an afterthought. Because it is built directly on top of NGINX, it can be configured as a reverse proxy in front of your Docker containers and VMs while applying configurable security policies that help detect and block SQL Injection (SQLi), Cross-Site Scripting (XSS), and automated brute-force scanners.
Core Security Layers Built Into BunkerWeb
Setting up NGINX with ModSecurity, OWASP rules, Fail2ban, and Certbot manually can take hours of complex configuration. BunkerWeb combines TLS automation, application filtering and configurable security plugins. Features and defaults depend on the integration and settings you enable:
- ModSecurity + OWASP Core Rule Set (CRS): Evaluates HTTP requests against enabled rules and uses configured anomaly thresholds to detect and block SQL injection, local/remote file inclusion (LFI/RFI), command injection, and XSS payloads.
- Automated Let's Encrypt TLS/SSL: Can provision and renew free Let's Encrypt certificates after you enable automation and configure HTTP-01 or DNS-01 validation. Check the effective TLS policy as part of deployment.
- Strict HTTP Security Headers: Can configure HSTS (
Strict-Transport-Security),Content-Security-Policy (CSP),X-Frame-Options, andX-Content-Type-Optionsheaders. - Bad Behavior & Rate Limiting: Request-rate limits and Bad Behavior are separate controls. Bad Behavior counts configured error responses per IP over a time window and bans clients when the threshold is exceeded.
- Antibot & Threat Intelligence Blocklists: Supports optional cookie, JavaScript or CAPTCHA challenges, external IP/DNS blocklists and CrowdSec. Antibot and AIO CrowdSec are disabled by default; enable them deliberately and test normal clients.
A challenge or successful WAF check does not authenticate a user or guarantee that a request is harmless. Keep application permissions and login controls in place. I consider the additional filtering worthwhile for public self-hosted services, with the maintenance and tuning it requires.
Deploying BunkerWeb with the All-In-One Image
The official AIO integration includes the proxy, scheduler and management UI in one image. That matters because starting only the standalone proxy container is not equivalent to deploying the complete management stack. This Compose example follows the documented 1.6.15 image and persists its data in a named volume. This is the stable version shown in the checked documentation, rather than an instruction to follow release-candidate tags. Read the release notes and upgrade guidance before selecting a different version. Docker Engine and the Compose plugin must already be installed; our Docker guide provides background.
services:
bunkerweb:
image: bunkerity/bunkerweb-all-in-one:1.6.15
container_name: bunkerweb-aio
restart: unless-stopped
ports:
- "80:8080/tcp"
- "443:8443/tcp"
- "443:8443/udp"
- "127.0.0.1:7000:7000/tcp"
volumes:
- bw-storage:/data
volumes:
bw-storage:Save the example as compose.yaml, run docker compose config to inspect the resolved configuration, then docker compose up -d from that directory. Check docker compose logs --tail=100 bunkerweb for startup failures. The loopback-only port 7000 mapping provides temporary access to the bootstrap UI from the Docker host. For a remote Linux server, use an SSH tunnel rather than exposing that direct management port to the internet. Follow the setup wizard to create the administrator account, configure the protected UI endpoint and add your application. Remove the temporary mapping when setup is complete and recreate the container from the updated Compose file. Protect the configured management endpoint too; moving it behind the proxy is not a substitute for authentication and access restrictions.
For an illustrative Nextcloud deployment, the public hostname might be cloud.example.net and the upstream http://192.168.1.20:8080. Substitute your own hostname and actual backend address. The backend must be reachable from the BunkerWeb container: localhost inside that container refers to the container itself. Keep the backend off public port-forwarding rules so visitors cannot bypass the WAF.
Plan resources before treating the stack as lightweight. The checked quickstart recommends two virtual CPUs and 8 GB RAM even for testing or very few services. Workload, rules and upload sizes affect resource needs. Large file uploads deserve specific tests because request-body inspection can consume memory.
Before Opening the Router
Write down the intended path: internet client, router, BunkerWeb, application. Confirm that ports 80 and 443 are not already claimed by another proxy. Verify public DNS points to your connection and that your ISP permits inbound service hosting. If you are behind carrier-grade NAT, a router forwarding rule alone cannot make your service reachable; resolve that connectivity constraint first.
Certificate issuance has its own prerequisites. HTTP-01 requires the validation service to reach port 80, while DNS-01 requires control over the relevant DNS records. A valid certificate establishes encrypted transport; it does not establish that your application is patched or that its accounts have strong authentication. Configure the application to trust the proxy correctly and keep administrative interfaces private where possible.
If a CDN or another proxy is in front, verify that logs show the intended client address. Configure Real IP only for the proxy addresses you trust; accepting forwarded addresses from arbitrary clients allows spoofing and can undermine IP-based bans. Treat the application-to-proxy trust relationship separately from the proxy-to-CDN relationship.
Check the Application, Not Just the Security Score
Use a small acceptance checklist before switching users to the proxy. Sign in and out, upload a harmless test file, download it, use the mobile client and exercise any webhooks. Check both the browser and application logs. A homepage loading successfully tells you little about background sync, large uploads or an API client that does not execute JavaScript.
SecurityHeaders and SSL Labs can help assess headers and TLS configuration, but neither score proves the whole service is secure. Avoid promising an automatic A+ rating: headers, certificate deployment, application behavior and optional features influence the result. Record the checks you actually performed so later changes have a useful comparison point.
A Practical False-Positive Workflow
Suppose a legitimate document upload receives a 403 response. Reproduce it with a harmless file, record the request time and URL, and inspect the matching ModSecurity event. Distinguish a WAF decision from an application permission error or a rate-limit ban. The troubleshooting guide explains how rule matches and anomaly scores appear in logs.
Start with a narrowly scoped exclusion for the affected application and rule, then repeat the normal upload and login checks. Do not disable the entire WAF to solve one broken feature. Detection-only mode is useful during controlled investigation, but it records matches without blocking them. Keep that testing phase bounded and restore enforcement after reviewing the results. Also check whether bot challenges are interfering with machine clients rather than assuming every rejected request is an attack.
Maintenance and Limits
Back up the persistent data before upgrades, keep the previous image version available and retain a way to restore the proxy configuration. When testing a new release, compare real application workflows rather than only checking that the container is running. Rotate logs and review recurring failures so the proxy does not become a neglected black box.
The HTTP setup shown here protects web services that pass through it. It does not replace router policy, cover an independently exposed SSH service, stop malware on a laptop or absorb an attack that saturates your internet connection. For a private family service, a VPN may be the simpler exposure model. For a public website, the WAF is one layer alongside application updates, account security and recoverable backups.
Pros and Cons of Running BunkerWeb at Home
Pros
- Comprehensive WAF Out of the Box: Combines reverse proxying, OWASP ModSecurity rules, rate limiting, and TLS automation in one stack.
- Optional Web UI & Docker Autoconf: Can be managed via environment variables, Docker container labels, or a full graphical admin dashboard.
- Open-Source Core: Core WAF and reverse-proxy capabilities are available in the community project; optional commercial features and support have separate terms.
Cons
- WAF False Positives Require Tuning: Strict OWASP Core Rule Set checks can occasionally block legitimate file uploads or complex API calls in apps like Nextcloud or WordPress until you add rule exclusions.
- Steeper Learning Curve Than Nginx Proxy Manager: Understanding ModSecurity paranoia levels and CSP headers takes some initial experimentation.
Conclusion
If you expose any self-hosted web services directly to the internet without a VPN, a forwarding-only proxy configuration leaves application filtering to other controls. BunkerWeb bridges that gap by wrapping NGINX with ModSecurity, OWASP CRS, rate limiting, and automated SSL certificates, adding a useful layer for the web services you intentionally publish. It remains a worthwhile option when you can maintain the applications, proxy policies and backups together.
Visit the official BunkerWeb Website and documentation to explore its full plugin library.
