Blackwall's $100 Million Bet on the Hosting Relationship

Blackwall's new funding round is a bet on who gets to sell security to the smaller businesses that make up the web. The company announced on October 20 that it had raised $100 million at a $2.2 billion valuation. Its proposition is not simply to place another filter in front of a website. It wants hosting providers to deliver that protection under their own brands, inside their existing commercial relationships. The provider remains the storefront, while Blackwall supplies the machinery.

Tech.eu reports that AVP led the Series C, with participation from Dawn Capital, MMC Ventures and Tera Ventures. It also reports plans to expand operations across twelve regions in North America, Europe, Asia-Pacific and the Middle East. Those are expansion plans, not twelve newly verified operating deployments. The financing is a company-announced raise corroborated by independent reporting. Neither the valuation nor the announcement establishes a revenue multiple, customer retention rate or return that an individual hosting partner will achieve.

The commercial design is unusually important here. Blackwall's website offers providers the ability to combine components, establish service tiers and include protection by default or sell it as an addition. That puts the decision about packaging close to the customer relationship. My reading is that Blackwall is selling providers a way to add another service without building the underlying security technology themselves. Whether customers will pay enough to justify operating and supporting that service remains a separate, local business question.

GateKeeper, the company's traffic-filtering product, makes that distribution strategy tangible. Blackwall describes a self-hosted deployment with a REST API and integrations for familiar hosting control panels. It advertises a web application firewall, caching, rate limiting and certificate management alongside bot mitigation. These are vendor-described capabilities, not results of testing by this publication. The breadth matters commercially: a provider can position a package around site operation and performance as well as attack prevention, rather than asking customers to understand every underlying security component.

The architecture documentation separates the work into layers. Incoming traffic first encounters network controls, then GateKeeper nodes acting as reverse proxies. A detection layer performs deeper behavioral analysis before accepted traffic reaches the hosting environment. Telemetry can also be exported for analysis. The important operating distinction is that filtering is placed ahead of the application. A request rejected there need not consume the same application-side work as one allowed through, although the documentation does not establish a universal percentage saving.

That placement has limits. The diagram includes optional network-layer DDoS mitigation before the reverse proxy, distinct from application-layer protection within GateKeeper. A provider should therefore avoid treating the existence of a web filter as proof that every upstream network bottleneck is protected. The architecture supplies a useful purchasing question: which component handles each failure or attack condition, and who operates it? That is a boundary to establish during service design, not an allegation that a particular customer's installation is missing protection.

The version 1.6 quick-start guide shows what self-hosting means in practice. It calls for a clean Debian 12 installation and describes a customized Nginx foundation, followed by account provisioning and domain configuration. This is an infrastructure deployment, even when a provider later exposes it to customers through a simple control panel. A buyer evaluating the channel proposition should include responsibility for that host and its configuration. Familiar web-server foundations may make the system more approachable, but familiarity is not an availability guarantee.

The same guide requires the master account API key to be provisioned in Redis and warns that it grants access to account and website data. Domain activation also depends on the owner's DNS change. These are different controls: possessing an account credential and proving control over a domain are not interchangeable events. An operational review should identify who handles each step and how credentials are protected. This article has reviewed the documentation, not installed the product or exercised those permissions.

A concrete default illustrates the difference between an attractive security description and an operating policy. Blackwall's rate-limit guide says GateKeeper blocks more than twenty-four new HTTP or HTTPS connections per second from one IP address. That is a connection threshold, not a count of page views, requests or individual people. The unit matters. Evaluating it against an application's request-rate dashboard alone could give a misleading picture of which traffic would be affected. The documented rule provides a specific condition to test with representative traffic.

The guide also describes changing persistent firewall rules on each GateKeeper server. That makes consistency across nodes part of the operator's responsibility. It does not justify disabling protection wholesale when an integration has trouble. A useful acceptance test would establish both whether unwanted bursts are constrained and whether required clients still work, with the same policy applied across the deployment. This is an evaluation recommendation, not evidence of a measured false-positive rate or a reported customer outage.

Traffic policy cannot be reduced to humans good, automation bad. Blackwall's core-rule documentation distinguishes search crawlers, social-network services and recognized cloud services from content scrapers, suspicious behavior and other categories. It recommends allowing the former groups as well as human visitors, while applying restrictions to the latter. The categories reflect a real business decision: some automated access supports discovery, previews or monitoring. Blocking all nonhuman activity would be a different product policy from selecting which automated relationships a site wants to maintain.

The interface offers allow and deny choices, with CAPTCHA available for some rules. Those controls let an administrator express policy; they do not prove perfect classification. A provider should ask how an incorrectly classified integration is identified, corrected and communicated to the customer. It should also make clear who can change a customer's policy. None of the reviewed core-rule documentation supplies an independently measured error rate, so claims that the system reliably understands every agent's intention would go beyond this evidence.

The WHMCS integration turns those choices into a sellable service. Its documentation says an administrator selects the components and functions included in a package, and the customer's assigned package determines which features become available. It also warns against managing the same deployment through GateKeeper directly and an integration module concurrently, because that can create conflicting configurations. This is a consequential ownership question for a hosting business: a security exception should have an authoritative management path, not two administrators unknowingly reversing each other's changes.

The integration guide separately exposes HTTPS to the origin and forced HTTPS for incoming visitors. A protected public connection should therefore not be treated as proof that the upstream connection has been configured the same way. It also cautions that dynamic-content caching can delay fresh content. Those settings deserve review when constructing service tiers. A performance bundle changes delivery behavior as well as a sales description, and the customer should understand that distinction before it is enabled.

Availability adds another layer of work. Blackwall's cluster guide recommends three or more GateKeeper servers, although it describes two as the minimum. Its example uses Redis Sentinel to select a replacement master and HAProxy to direct local connections to the current master. This addresses a specific dependency within the deployment. The presence of several machines does not, by itself, establish that every part of a request's path survives a failure. The guide's narrower description is more useful than an undifferentiated promise of redundancy.

In particular, the guide explicitly does not configure public HTTP and HTTPS load balancing. It calls for a separate ingress arrangement, such as a load balancer or DNS failover, with GateKeeper health checks. It also includes failover and sequential-reboot verification. A provider designing a customer-facing availability commitment must account for that remaining ingress layer and test the complete service. No guaranteed recovery time follows from reading the procedure, and this publication has not run its failure tests.

Blackwall is not alone in giving site owners choices about automated access. Cloudflare's AI Crawl Control documentation describes per-crawler allow and block decisions, with charging available through a closed beta. It also distinguishes detection based on self-identifying user-agent strings on the free plan from deeper detection on upgraded plans. These qualifications matter when comparing offerings. A dashboard containing a crawler name is not the same evidence as a system demonstrating how it handles automation that does not identify itself honestly.

The payment option should be interpreted just as carefully. Cloudflare labels pay per crawl as closed or private beta in the reviewed guide, rather than a universally available revenue stream. That is useful counterweight to sweeping predictions about websites collecting money from every visiting agent. Access control, detection and commercial settlement are related but separate capabilities. A hosting provider can have a defensible security service without promising an agent-payment business that its chosen product and customer agreements do not yet establish.

The practical attraction of Blackwall's approach is control over delivery. Its product material describes providers maintaining their own policies, access management and billing automation while offering security as a built-in feature or premium addition. That gives a service operator choices, but also creates work it must price. For a prospective partner, the relevant comparison is the complete service it can support: integration, configuration ownership, incident handling and customer communication. A supplier's feature list is only one input to that decision.

For the website owner, the funding headline will be less important than the service agreement from the host. Who can authorize a crawler? Who answers when a required integration is blocked? Does the purchased tier include the control needed to correct it? Those questions connect Blackwall's technical design directly to its channel economics. Retaining the customer relationship is valuable only if the provider can also explain and operate the service. The investment thesis now has to survive that customer-facing test, one hosting partner at a time.

LaunchPad positionA hosting provider keeps the customer relationship, but must also own the policy, support and availability commitments behind its security package.