BunkerWeb Cloud is the fully managed version of BunkerWeb, the open-source firewall covered in the previous article on this site. The self-hosted version has a real capacity ceiling — Bunkerity’s own quickstart guide recommends 2 vCPUs and 8GB of RAM for testing, 4 vCPUs and 16GB for production with multiple services. That ceiling matters specifically when an attack involves volume, not just malicious requests. Cloud’s pitch is that it removes that ceiling. Whether that matters depends entirely on what you’re actually defending against.

What It’s Actually Built to Stop

Bunkerity’s own Cloud page confirms the engine underneath is ModSecurity paired with Lua — the same combination documented for the self-hosted core. The OWASP Core Rule Set and the bot-challenge system (cookie checks, JavaScript tests, CAPTCHA) aren’t named specifically on the Cloud page itself, but they are named, documented features of the underlying BunkerWeb engine, and Cloud’s own pricing page states plainly that it includes “all the power of BunkerWeb PRO.” Since PRO runs on that same documented core, it’s a reasonable inference that these features carry over to Cloud — but it’s an inference, not a line lifted from a Cloud-specific page, and that distinction is worth keeping straight rather than blurring into one confident claim.

Comparing the two directly: for most attack categories, Cloud doesn’t protect any better than the free, self-hosted version, since both run the same rules. The one area where it’s a meaningfully different defence — not just a more convenient one — is large-scale volumetric DDoS, where having elastic infrastructure behind it matters more than which detection rules are running.

The One Step That Determines Whether Any of This Works

Here’s the actual sequence, based on Bunkerity’s documentation: a visitor’s browser resolves your domain to BunkerWeb Cloud via the CNAME record, so the request arrives at Cloud’s infrastructure first, not your server. The ModSecurity-plus-Lua engine inspects it against the rule set there — blocking known attack patterns, applying rate limits, running bot challenges where configured. If the request passes inspection, Cloud forwards it over HTTPS to your origin server, which processes it exactly as it would if BunkerWeb weren’t involved at all; your application code doesn’t know or need to know the firewall exists. The response then travels back through Cloud to the visitor. None of that changes how your application works — it only changes what’s allowed to reach it in the first place.

That’s standard for any DNS-based WAF, including the larger commercial ones. But it creates a structural gap that has nothing to do with how good the detection rules are.

This isn’t unique to BunkerWeb — every reverse-proxy-based WAF, Cloudflare included, has the same exposed-origin problem unless it’s closed off. Closing it isn’t automatic, though; it’s a step someone has to actively configure, and skipping it means paying €639 a month for a firewall an attacker can simply walk around.

Closing the Gap: What Bunkerity’s Own Setup Guide Actually Tells Admins to Do

Here’s the setup sequence from Bunkerity’s own tutorial, with the security reasoning attached to each step:

• Choose a plan and set your starting resources. Default allocation is 2 vCPUs and 8GB of RAM, replicated across two nodes for high availability — this is the baseline you scale up from as the number of protected services grows.
• Add the CNAME record, then wait for propagation. Traffic doesn’t route through Cloud the instant you save the DNS change — propagation delay means there’s a window where protection isn’t active yet, worth accounting for if you’re migrating a live site.
• Register each service individually in the Cloud dashboard. Pointing DNS at BunkerWeb Cloud doesn’t automatically protect anything — each domain or service has to be explicitly added in the control panel before it’s covered.
• Whitelist BunkerWeb Cloud’s IP addresses on your own backend firewall. This is the step that actually closes the bypass risk above — without it, your origin server still accepts connections from anywhere, not just from Cloud.
• Enforce HTTPS on the connection between Cloud and your backend, not just between visitors and Cloud. It’s easy to assume the whole path is encrypted once HTTPS is working for visitors; the leg between Cloud and your origin server needs to be configured separately.
• Use the monitoring dashboards to watch for traffic spikes before they become a problem. Every Cloud plan includes pre-built dashboards — checking them proactively is what turns “monitoring” from a feature into something that actually catches an attack early.
• Set up alerts for 5xx errors and abnormal traffic surges. Without alerting configured, an ongoing attack or a misconfiguration can sit unnoticed until someone happens to check the dashboard.
• Review the automated reports once they start arriving. Bunkerity’s Reporting plugin, included in Cloud, generates weekly or monthly summaries of traffic and blocked threats — reading these regularly turns the data into an early-warning signal instead of a log nobody opens.

What’s Included, Briefly

The Essential tier starts at €639 per month and bundles the full PRO plugin set — Anti-DDoS, S3 backup, database migration tooling, a Prometheus metrics exporter, automated threat reporting, and user/access management — along with a monitoring platform tracking latency, load, blocked threats, and centralised logs, plus direct support from BunkerWeb’s maintainers. Default resource allocation starts at 2 vCPUs and 8GB of RAM, replicated across two nodes for high availability — that’s the baseline the elastic scaling builds out from as traffic grows. Bunkerity also states it handles automatic updates, security patches, and regular backups as part of the service. Pricing scales with the number of protected services and allocated resources; setups beyond roughly 50 protected services move to a custom quote. Certified hosting — ISO 27001, HDS, SecNumCloud — is available on request, relevant specifically where the hosting environment itself is a regulatory requirement, as in healthcare or finance.

Free Self-Hosted vs. PRO Self-Hosted vs. Cloud

Why Use It, and Why Not

My Take — Mr Wangdoo

This observation comes from reading BunkerWeb’s own documentation and cross-referencing it against multiple sources — the Cloud page, the pricing page, and the setup tutorial — not from running the service. Read that way, the case for BunkerWeb Cloud is narrower than the marketing framing suggests. For the bulk of what a WAF normally catches — injection attempts, bot floods, known-bad IPs — the documentation describes the free, self-hosted version running the identical rule engine. The one clearly documented upgrade is elastic capacity against large-scale volumetric DDoS, a more specific need than “better security” as a general claim.

The detail that stood out most across that research was the origin-IP whitelisting step. It isn’t hidden — Bunkerity’s own setup guide states it plainly — but it would be easy to assume a fully managed service handles that end to end without being told otherwise. Based on the documentation alone, the more accurate way to put it is that Cloud’s protection is conditional on that one configuration step being completed correctly, and that’s a detail worth weighing alongside the monthly cost when deciding whether the managed convenience makes sense for a given setup.