Skip to content

Vercel WAF vs Arcjet

Arcjet is an alternative to Vercel WAF for protecting your applications from bots, attack traffic, and abuse. Both products offer WAF and bot detection features, but they operate at fundamentally different layers and have different configuration models.

  1. Where security runs: Vercel WAF runs at the network and CDN edge — rules are evaluated before requests reach your application code. Arcjet runs inside your application as a library, evaluated from within your request handlers and middleware. This distinction shapes almost every other difference. Network layer rules act on a limited, fixed set of signals (IP, user agent, TLS fingerprint, URL path, headers). In-code rules have access to your full request context: session tokens, database-backed subscription levels, feature flags, route-specific logic, and anything else your application knows about a request.

  2. Configuration model: Vercel WAF is configured entirely in the Vercel dashboard and published as infrastructure changes — no library to import, no code to write. Arcjet rules are written in your application code, live in your repository, are reviewed in pull requests, deployed with your application, and can branch on any runtime condition. Vercel does offer a limited vercel.json code path, but it only supports challenge and deny actions — logging, bypass, and redirect are dashboard-only, and there is no support for per-request dynamic logic. For the operational changes where dashboard speed matters — blocking a country during an attack, tightening a global rate limit, temporarily denying an IP range — Arcjet Remote Rules apply without a redeploy too, from the Arcjet dashboard or the Arcjet MCP server. Code-defined rules and remote rules evaluate together into a single decision.

  3. Platform independence: Arcjet is platform-agnostic and works wherever you can run a JavaScript, TypeScript, or Python application — Vercel, Netlify, Fly.io, Render, AWS, Kubernetes, or self-hosted. Vercel WAF only works for applications hosted on Vercel.

  4. Bot detection: Vercel’s Bot Protection managed ruleset identifies clients that violate browser-like behavior and serves a JavaScript challenge. It is available on all plans (Hobby, Pro, Enterprise). However, Vercel’s own documentation warns that it does not work correctly behind a reverse proxy (Cloudflare, Azure CDN, etc.) — the proxy masks detection signals, causing false positives and frequent re-challenges due to rotating exit IPs. Arcjet bot detection classifies known bots by name and category and uses real-time threat feeds for attack intelligence. On top of that, Arcjet advanced client signals load a WebAssembly module that collects browser-environment anomalies (headless markers, automation framework fingerprints, browser-quirk inconsistencies) and persists a continue token in the aj_signals cookie reused across navigations. Server-side detectBot evaluates signals alongside user-agent classification, IP reputation, and an optional missing-cookie filter rule in a single decision, with LIVE / DRY_RUN rollout modes and an inspectable ARCJET_SIGNALS denial reason. It runs inside your application, so reverse proxies in front of your origin don’t break it.

  5. AI app protection: Vercel’s AI Bots managed ruleset (available on all plans) blocks AI crawlers scraping your content with Log or Deny actions. Arcjet’s AI bot category does the same and is also available on all plans. Beyond crawler blocking, Arcjet’s AI Runtime Protection protects the AI application itself: detecting prompt injection, enforcing per-user token budgets, and preventing PII from leaking into model context. Vercel WAF has no equivalent at the application layer.

  6. Agentic workloads and non-HTTP entry points: Vercel WAF only sees inbound HTTP requests at the edge — it can’t inspect what happens after a request enters your application. That blind spot is where most agent damage actually occurs: a model fetches a web page, then re-enters its context loaded with hidden instructions; a tool call burns tokens in a runaway loop; a background job ships a support ticket to a third-party LLM with PII attached. None of these surface as a fresh HTTP request the WAF can rule on. Arcjet Guards applies the same primitives — token-bucket rate limiting, prompt injection detection, PII detection — inline at the points an agent actually fans out: inside MCP tool handlers, between agent steps, in queue consumers, and across multi-service pipelines. You call guard() with the input directly; no Request object required. Rules and modes (LIVE / DRY_RUN) are the same shape as HTTP rules, so a single policy can span your route handlers and your agent code.

  7. Rate limiting: Vercel WAF rate limiting is request-count based. On Hobby and Pro, the only counting keys are IP and JA4 Digest; User Agent and arbitrary header keys are Enterprise-only. Per-user or account-level rate limiting therefore requires Enterprise and requires your application to pass an identifying header for the WAF to key on — the WAF has no concept of your application’s users. Token Bucket algorithm is Enterprise-only; the maximum window on Hobby and Pro is 10 minutes (1 hour on Enterprise). Number of rate limit rules per project is 1 on Hobby, 40 on Pro, 1000 on Enterprise. Arcjet rate limiting is configured in code, can be keyed on any value your application can compute (user ID, account, session, plan tier), and supports Token Bucket with windows up to 24 hours.

  8. Plan gating: The most capable Vercel WAF features — OWASP Core Ruleset (Enterprise-only), Token Bucket rate limiting (Enterprise-only), non-IP/non-JA4 rate-limit keys (Enterprise-only) — sit behind Enterprise (“Contact sales”). Bot Protection and AI Bots managed rulesets are now available on all plans. Arcjet’s advanced features (advanced bot detection, IP reputation, advanced signals, AI Runtime Protection, Guards) are available on self-serve plans.

AreaArcjetVercel WAF
Where it runsInside your application, as a library called from handlers and middleware.At the network/CDN edge, before requests reach your application.
ConfigurationRules-as-code in your application; committed to your repo, reviewed in PRs, deployed with your app. Can branch on any runtime value. Remote Rules add dashboard- or MCP-managed rate limit, bot, filter, and Shield rules that take effect immediately without a redeploy.Dashboard UI (publish within 300ms without redeployment). Limited vercel.json support for challenge/deny only — no log, bypass, or dynamic logic.
HostingPlatform-agnostic. Works on any provider or self-hosted infrastructure.Vercel only.
Languages & frameworksJavaScript, TypeScript, and Python. Native SDKs for Next.js, Node.js, Bun, Deno, Remix, SvelteKit, NestJS, React Router, Fastify, Astro, Python FastAPI, Flask, and other Python web servers.Any language hosted on Vercel. WAF rules apply at the network layer regardless of framework.
Bot detectionKnown bots classified by name and category in code; browser-based WebAssembly advanced signals detect headless browsers without CAPTCHAs. Works behind any proxy or CDN.Bot Protection managed ruleset (all plans) uses JS challenge; explicitly documented as broken behind reverse proxies (Cloudflare, Azure CDN, etc.).
AI bot blockingAI crawler category (CATEGORY:AI) configured in code alongside other bot rules.AI Bots managed ruleset (all plans); automatically maintained by Vercel. Log or Deny only.
AI app protectionAI Runtime Protection: prompt injection detection, per-user token budgets, PII detection in AI flows — protects AI application logic, not just content scraping.No protection for AI application layer (no prompt injection, no token budgets, no PII in AI flows).
Agentic / non-HTTPArcjet Guards: call guard() directly from MCP tool handlers, between agent steps, inside queue consumers, and across multi-service pipelines. Same rule primitives (token bucket, prompt injection, PII detection) as HTTP, same LIVE/DRY_RUN modes. JS/TS via @arcjet/guard; Python via arcjet.No equivalent. Vercel WAF only inspects HTTP requests transiting the edge — it cannot see tool calls, queued jobs, or fan-out work inside the application. Vercel Functions and route handlers can host application logic, but the WAF doesn’t gate what happens once a request lands.
WAF / attack coverageShield WAF detects and blocks common web attacks (SQLi, XSS, path traversal, etc.).OWASP Core Ruleset (Enterprise-only). Platform-level DDoS mitigation (L3/L4/L7) is automatic and free on all plans.
Rate limitingRules-as-code; key on user ID, account, session, plan, or any computed value. Token Bucket on all plans.Hobby/Pro: keyed on IP or JA4 Digest only. User Agent and arbitrary header keys are Enterprise-only. Token Bucket is Enterprise-only. Max window 10 min on Hobby/Pro, 1 hour on Enterprise. Rules per project: 1 (Hobby), 40 (Pro), 1000 (Enterprise).
Filter rulesExpression-based filter rules in code; compose cookie, IP reputation, geo, VPN/proxy, header, and path conditions alongside bot and rate limiting rules. Powered by Rust/WebAssembly, evaluated locally.Custom rules in dashboard with similar condition types (IP, geo, path, header, JA4 Digest, user agent). Log action is Enterprise-only. Logic is static — no runtime branching on app context.
IP blockingVia filter rules in code; compose with other rules.Project-level and account-level IP blocking are available; account-level requires the relevant permission. Specific per-plan rule counts are not publicly documented.
Local developmentSame behavior as production; inspect decisions directly in code.WAF rules don’t apply locally; vercel dev bypasses the WAF entirely.
  • You want security as code You want your security rules in your repository, reviewed like any other change, testable in CI, and deployable with your application. You don’t want to manage a separate dashboard in sync with your codebase.

  • You need per-user or account-level logic Rate limiting by subscription tier, bot rules that vary by route or user role, or any decision that depends on something your application knows at runtime — these require code, not network-layer rules.

  • You deploy outside Vercel, or might in future Arcjet works on any platform: Vercel, Netlify, Fly.io, Render, AWS, Kubernetes, or self-hosted. Your security rules travel with your application code.

  • You’re behind a CDN or reverse proxy Vercel’s Bot Protection is documented as broken in this setup. Arcjet runs inside your application and is not affected by what sits in front of it.

  • You’re building AI applications Protecting against AI scrapers is different from protecting your AI application itself. Arcjet covers both: bot rules block automated clients, and AI Runtime Protection adds prompt injection detection, per-user token budgets, and PII detection in AI flows.

  • You’re shipping an agent, MCP server, or background pipeline Vercel WAF inspects inbound HTTP only; the risky surface in agentic code is what happens after the request enters your app — tool calls that re-enter the model with attacker-controlled content, runaway loops that burn tokens, and fan-out jobs that ship PII to third-party models. Arcjet Guards runs the same primitives inline at those points.

  • You want advanced bot signals Arcjet’s browser-based WebAssembly signal collection detects headless browsers and sophisticated scrapers without CAPTCHAs, and filter rules enforce cookie presence for requests that never touch the browser.

  • You want OWASP protection without Enterprise pricing Arcjet Shield WAF is available on self-serve plans. Vercel’s OWASP Core Ruleset is Enterprise-only.

  • You want zero-code infrastructure protection You want a firewall you can configure via a dashboard and publish instantly without touching your application code. You’re happy with static rules and don’t need runtime context from your application.

  • You need L3/L4/L7 DDoS mitigation Vercel’s automatic platform-level DDoS protection is free on all plans and doesn’t require any configuration. For large, distributed layer-3/4 attacks on hosting infrastructure, a network-layer firewall is the right tool.

  • You need TLS fingerprinting rules Vercel WAF supports the JA4 Digest as a rule condition, which is useful for blocking distributed attacks that rotate IPs but share a common TLS fingerprint.

In short: if your primary need is infrastructure-level DDoS protection or simple network-layer filtering as a quick-response tool, Vercel WAF is useful. If you need security that understands your application — who is making a request, at what plan, on which route, for what purpose — Arcjet is the better fit.

Can I use Arcjet and Vercel WAF at the same time?

Section titled “Can I use Arcjet and Vercel WAF at the same time?”

Yes. Vercel WAF and Arcjet are complementary layers. Vercel WAF’s automatic DDoS mitigation is always on and free — you don’t need to opt out of it. You can use Vercel WAF for coarse network-layer filtering (IP blocks, geo restrictions, rate limiting on public endpoints) while using Arcjet for fine-grained application-level security: per-user rate limits, bot detection with full request context, advanced signals, and AI protection. Arcjet rules run after the request passes through the Vercel network layer.

Does Vercel WAF protect my AI application?

Section titled “Does Vercel WAF protect my AI application?”

Vercel’s AI Bots managed ruleset blocks AI crawlers from scraping your content — it is a content protection tool. It does not protect AI application logic. Arcjet’s AI Runtime Protection is designed for this use case: blocking automated clients from exhausting AI budgets, detecting prompt injection attacks before they reach your model, enforcing per-user token quotas, and preventing PII from entering AI context.

What about my agent’s tool calls, queue workers, and pipelines?

Section titled “What about my agent’s tool calls, queue workers, and pipelines?”

Vercel WAF only sees inbound HTTP requests at the edge. Once a request is inside your application, anything an agent does next — fetching a web page and re-feeding it to the model, calling tools in a loop, shipping work onto a background queue, fanning out across services — is invisible to the WAF. Those are the points where most agent abuse and cost-runaway happens. Arcjet Guards applies token-bucket rate limiting, prompt injection detection, and PII detection inline at those points. You call guard() with the input directly (no Request needed); rules are the same shape as your HTTP rules, so policy stays consistent between routes and agent code. Available in JS/TS via @arcjet/guard and Python via arcjet.

Does Vercel WAF work in local development?

Section titled “Does Vercel WAF work in local development?”

No. Vercel WAF rules only apply to traffic routed through the Vercel network. Running vercel dev or a local dev server bypasses the WAF entirely. This means you cannot test WAF behavior locally without deploying to Vercel. Arcjet runs inside your application and behaves the same in local development as in production.

Does Vercel WAF support per-user rate limiting?

Section titled “Does Vercel WAF support per-user rate limiting?”

Not natively. Vercel WAF rate limiting keys on network-level identifiers: IP address, JA4 fingerprint, user agent, or a specific header value. To rate limit by user or account, your application would need to pass an identifying header that the WAF can use as a key. There is no concept of authenticated users, session context, or subscription tiers in WAF rules. Arcjet rate limiting is configured in code and can key on any value your application can compute — user ID, account, plan, session, or any other identifier.

What happens if I’m behind Cloudflare or another CDN?

Section titled “What happens if I’m behind Cloudflare or another CDN?”

Vercel’s Bot Protection managed ruleset is explicitly documented as not working correctly behind reverse proxies like Cloudflare or Azure CDN. The proxy masks the signals used for detection, which causes false positives and frequent re-challenges. If you use a CDN in front of Vercel, Vercel’s bot detection is unreliable. Arcjet runs inside your application code and does not depend on network-layer signals — it works correctly regardless of what sits in front of it.

Discussion