Inside Protectd: How Vercel Retooled Its DoS Defense Pipeline

Vercel has long run always-on denial-of-service (DoS) mitigations across its platform, blocking traffic before it reaches customer deployments. Last year, the company made those protections visible with the Vercel Firewall, which lets users inspect traffic and apply custom rules. Now Vercel is introducing Protectd, a real-time security engine that replaces the polling-based detection pipeline behind those mitigations. The result: time to mitigation (TTM) for novel DoS attacks has dropped by more than tenfold.

The original four-phase mitigation stack

Before Protectd, Vercel's DoS defenses were organized into four phases, each handling a different layer of the network stack before a request could reach a deployment.

Phase 1: Point-of-presence mitigations. Requests first ingress through points of presence (PoPs), which terminate TCP and forward traffic to the nearest Vercel region. PoPs handle the most common L3/L4 attacks such as SYN floods and UDP reflection.

Phase 2: Transport-layer redundancy. A second L4 filtering layer uses state data to block attacks requiring deeper inspection, including connection floods and stateful TCP exhaustion.

Phase 3: In-band application-layer mitigations. The TLS termination service completes handshakes and runs L7 checks in-band, matching requests against common attack signatures for things like path traversals and malformed requests.

Phase 4: Out-of-band application-layer analysis. A dos-mitigation-controller analyzed network events (netlogs) in a global ClickHouse cluster, tracking attributes such as JA4 fingerprints, User-Agent strings, IP addresses, and request patterns. Netlogs flowed through a FluentBit sidecar to a Vector cluster for enrichment with geolocation, ASN, and hosting-provider data before landing in ClickHouse. When an attack pattern surfaced, mitigation signatures were distributed to all TLS terminators via an event bus.

Why the global aggregation model broke down

The original system filtered high volumes of traffic reliably, but its out-of-band detection had a critical weakness: TTM often exceeded 20 seconds. With roughly 85% of all L7 protections depending on that pipeline, the delay mattered. Vercel's own infrastructure can absorb L7 floods, but prolonged attacks risk overwhelming customer backends and driving up usage.

The bottleneck was architectural. Ingesting and materializing events in ClickHouse was slow and compute-heavy, and the polling-based approach for retrieving updates added further latency. The controller also resisted iteration: new mitigations often required writing new materializations and queries, slowing the response to emerging threats.

Protectd: edge detection, real-time enforcement

Protectd is a stream processor optimized for vertical scaling, built on a custom event-processing library. It shifts detection from global aggregation to the edge, replacing polling with real-time signal propagation. That architectural change is what enables the tenfold improvement in mitigation speed.

Running in every region, Protectd ingests enriched network events as newline-delimited JSON (ndjson) over persistent TCP connections from the existing FluentBit netlog forwarders. Eliminating polling lets Protectd respond to evolving attack patterns as they happen.

The engine is written in Golang, chosen for its concurrency model, lightweight runtime, and existing adoption across Vercel's edge and security systems. Protectd's performance is notable: it processes approximately 550K events per second globally, executing millions of defense decisions per second on just 14 CPU cores. That throughput relies on a JIT and SIMD JSON serialization library, event-time virtualization, and fast probabilistic data structures.

ClickHouse still has a role: it powers long-term traffic intelligence and surfaces complex behavioral signals. But the detection path no longer waits on it. Protectd processes live signals as they arrive, continuously mapping relationships between traffic attributes—TLS fingerprints tied to specific User-Agent strings, ASN and IP reputation, behavioral anomalies in request flows.

When Protectd identifies a suspicious pattern, it pushes defensive signatures directly to the event bus within the same region, where TLS terminators quickly enforce them. Keeping detection and enforcement local delivers rapid TTM while building a dynamic picture of the underlying attack.

Shadow mode, backtesting, and staged rollouts

Protectd includes validation mechanisms for every new filter. Each rule begins in shadow mode, passively flagging suspicious traffic without blocking it. Those shadow actions are logged and analyzed in the ClickHouse cluster to measure accuracy, impact, and false positive rates before enforcement begins.

Rules also support percentage-based rollouts, deploying progressively while monitoring challenge solve rates. For iteration, Protectd records every processed event, enabling historical traffic replay. That allows Vercel to snapshot past attacks and test new mitigations in a sandboxed environment.

Results since full rollout

Protectd rolled out fully in January 2025, after beginning in November 2024. Since then, every Vercel user has been on the new infrastructure. The system consistently delivers a P99 time to mitigation of 3.5 seconds, a P50 of 2.5 seconds, and can respond to threats in as little as 0.5 seconds.

The system has also caught L7 events that other defenses missed. Over 5% of attacks stopped by Protectd had already bypassed non-Vercel upstream proxies, indicating gaps in traditional CDN-layer DoS defenses.

Vercel continues to iterate on Protectd as the threat landscape shifts, and invites reports of DoS attacks that are not fully mitigated.