vercel firewall

The vercel firewall command is used to inspect and configure the Vercel Firewall from the command line, including traffic, custom rules, managed bot rules, IP blocks, system bypass rules, attack challenge mode, and system mitigations. You can match traffic with condition parameters and actions, stage updates to rules and IP blocks as drafts, and publish them when you are ready.

For more information about Vercel Firewall, see the Vercel Firewall documentation.

The vercel firewall command supports the following operations:

• overview - Show firewall configuration with the last day of activity
• status - Show firewall configuration in execution order
• traffic - Explore firewall traffic by action, client, and rule
• alerts - List and inspect firewall alerts
• persistent-actions - List and inspect actions applied to specific clients
• rules - Manage custom firewall rules and managed bot rules
• bot-management - List managed bot rules and unknown bot traffic
• ip-blocks - Manage IP blocks
• system-bypass - Manage system bypass rules
• attack-mode - Enable or disable Attack Mode
• system-mitigations - Pause or resume automatic DDoS mitigation
• Staging and publishing - Review, publish, or discard staged changes with diff, publish, and discard

Custom rule, managed bot rule, and IP block changes are staged until you run publish. System bypass, attack challenge mode, and system mitigations apply immediately.

Show your project's firewall configuration together with the last day of activity. The configuration block covers active rules, IP blocks, bypasses, managed rulesets, attack challenge mode status, and unpublished draft changes. Beneath it, the activity window reports traffic by action with a trend for each, the busiest rules resolved to their names, and any alerts raised in the same period.

vercel firewall overview

Traffic, rule attribution, and alerts are team-scoped. The activity window is the last 24 hours, which every team plan retains, so this command does not need an Observability Plus subscription. See Traffic for the retention that bounds the other traffic commands. Without a team scope, the command reports the configuration block on its own.

Options:

• --json: Output as JSON, including the activity period, totals, and the series behind each trend
• --project <name-or-id>: Project name or ID, defaulting to the linked project

Examples:

# Show configuration and recent activity
vercel firewall overview
 
# Report the same data as JSON
vercel firewall overview --json

Show firewall configuration in the order it is evaluated: bypass, then system mitigations, attack challenge mode, IP blocks, custom rules, and the managed rulesets for Bot Protection, AI Bots, and OWASP.

vercel firewall status

Reach for status when you need to reason about which check runs first, and overview when you also want recent traffic and alerts.

Options:

• --json: Output as JSON
• --project <name-or-id>: Project name or ID, defaulting to the linked project

Report the requests the firewall acted on. traffic list answers what happened across the project. traffic inspect takes one value from those lists and shows only its traffic. Both are read-only and need a team scope.

How far back you can read is bounded by your plan's firewall data retention. Observability Plus extends that retention to 30 days.

The CLI allows a query only when --since falls inside the data your plan still keeps. Shortening the window with --until does not help if --since is already too far back.

Both subcommands describe traffic with the same 10 dimensions: ip, ja4, asn, user-agent, path, rule, host, bot, country, and action. Each dimension plays three roles:

• traffic list reports it as a top list, which you choose with --dimension
• traffic inspect takes it as the dimension to inspect, or as --group-by
• A flag of the same name narrows either report to matching requests, such as --ip 1.2.3.4 or --action deny

You can combine the narrowing flags with each other and with --filter.

--since and --until both accept a relative offset (1h, 24h, 7d) or an ISO 8601 date.

Aliases: ls.

Show requests by firewall action over a window, with a trend and total for each action, followed by a top list per dimension: the busiest client IPs, JA4 TLS fingerprints, autonomous systems, user agents, request paths, rules, hostnames, and verified bots.

vercel firewall traffic list

The command prints the window, requests by action, then a top list per dimension:

  Firewall traffic  Sep 6 12:00 – Sep 7 12:00 UTC · 24 points (1h each)

  Requests by Action
  Action   Trend    Total  Peak  Peak at
  Allow    ▁▃▆█▆▃▁  40.0k  2.1k  14:00
  Deny     ▁▃█▆▃▁   2.4k   1.5k  13:00

  Top IPs
  1.2.3.4           1.8k
  5.6.7.8           600

  Rules
  DDoS Mitigation   2.4k

  Verified Bots
  github-hookshot   900

  Break any of these values down further:
  vercel firewall traffic inspect <dimension> <value>

The default report also includes top lists for JA4 digests, AS names, user agents, request paths, and hosts.

Each top list is its own query. A dimension your account cannot report marks that list unavailable instead of failing the command. The rule list shows a rule's name where the firewall configuration names it. --json keeps the rule id as value for traffic inspect.

Options:

• --json: Output as JSON, including the period, per-action totals and series, and each top list
• --project <name-or-id>: Project name or ID, defaulting to the linked project
• --since <time>: Start of the window. Defaults to 24 hours ago
• --until <time>: End of the window. Defaults to now
• --top <number>: Rows per top list. Defaults to 5
• --dimension <dim>: Top list to include, from the dimensions above. Repeatable, or comma-separated. Defaults to every dimension except country and action
• --alert <alert-id>: Scope the window and rule to one alert from alerts list
• --filter <expr>: KQL filter expression. Repeatable, ANDed together
• --ip <ip>, --ja4 <digest>, --asn <name>, --user-agent <ua>, --path <path>, --rule <rule-id>, --host <hostname>, --bot <bot>, --country <code>, --action <action>: Narrow every top list to requests matching the given dimension value

Examples:

# Show traffic from the last day
vercel firewall traffic list
 
# Show the last hour, with the top 20 rows per list
vercel firewall traffic list --since 1h --top 20
 
# Show which countries and user agents denied traffic came from
vercel firewall traffic list --action deny --dimension country --dimension user-agent
 
# Scope the report to the period and rule of one alert
vercel firewall traffic list --alert al_abc123

Show one dimension value in detail: its requests by action over the window, and a breakdown of that traffic by a second dimension. Pass one of the dimensions above and one of its values, such as an IP from the Top IPs list.

vercel firewall traffic inspect <dimension> <value>

The command prints the value, its requests by action, and a breakdown by a second dimension:

  1.2.3.4  IP Address
  AS Name         EXAMPLE-AS
  AS Number       64500
  Country         DE
  Requests        2.4k

  Requests by Action  Sep 6 12:00 – Sep 6 12:15 UTC · 2 points (15m each)
  Action   Trend  Total  Peak  Peak at
  Deny     ▁█     2.4k   1.5k  12:15

  Breakdown by Request Path  (top 10)
  Request Path  Trend  Total  Peak  Peak at
  /api/login    ▁█     2.0k   1.2k  12:15
  (not set)     █▁     400    400   12:00

The breakdown dimension defaults to whichever pairs best with the one being inspected: paths for a client, clients for a path or a rule. Use --group-by to choose another, naming any dimension but the one being inspected. Inspecting a rule takes the rule id. traffic list shows the rule's name in text output and the id as value in --json.

Options:

• --json: Output as JSON, including the period, totals, series, and the breakdown with a series per row
• --project <name-or-id>: Project name or ID, defaulting to the linked project
• --since <time>: Start of the window. Defaults to 24 hours ago
• --until <time>: End of the window. Defaults to now
• --group-by <dim>: Dimension to break the traffic down by. Defaults to the one that pairs with the inspected dimension
• --top <number>: Rows in the breakdown. Defaults to 10
• --alert <alert-id>: Scope the window and rule to one alert from alerts list
• --filter <expr>: KQL filter expression. Repeatable, ANDed together
• --ip <ip>, --ja4 <digest>, --asn <name>, --user-agent <ua>, --path <path>, --rule <rule-id>, --host <hostname>, --bot <bot>, --country <code>, --action <action>: Narrow the inspected value further, to requests matching the given dimension value as well

Examples:

# Inspect one client IP
vercel firewall traffic inspect ip 1.2.3.4
 
# See which IPs a rule acted on
vercel firewall traffic inspect rule rule_abc123 --group-by ip
 
# Inspect a path over the last week
vercel firewall traffic inspect path /api/checkout --since 7d
 
# Narrow one client to what the firewall denied
vercel firewall traffic inspect ip 1.2.3.4 --action deny

A value with no traffic in the window returns a not-found error, not an empty report. Otherwise a typo and a quiet client would look the same:

Error: No firewall traffic for IP Address "9.9.9.9" in this window. Run vercel firewall traffic list to see which values have traffic, or widen the window with `--since`.

Firewall alerts record periods when the platform detected and mitigated anomalous traffic, including DDoS mitigation episodes. Alerts are read-only and require a team scope.

Aliases: ls.

List firewall alerts raised in a window, active ones first. Each row carries the alert's id for use with alerts inspect.

vercel firewall alerts list

Options:

• --json: Output as JSON
• --project <name-or-id>: Project name or ID, defaulting to the linked project
• --since <time>: Start of the window, relative (24h, 7d) or an ISO date. Defaults to 24 hours ago
• --until <time>: End of the window. Defaults to now

Examples:

# List alerts from the last day
vercel firewall alerts list
 
# List alerts from the last week
vercel firewall alerts list --since 7d

Show one alert in detail: the window it covers, the request rate during it compared with the preceding day, the hosts it affected, and the IPs denied while it was active.

vercel firewall alerts inspect <alert-id>

Options:

• --json: Output as JSON
• --project <name-or-id>: Project name or ID, defaulting to the linked project

Examples:

# Inspect an alert by id
vercel firewall alerts inspect al_abc123

The chart reaches a day further back than the alert to compare it against. On Pro that lands outside firewall retention, so Pro needs Observability Plus for the traffic and rate figures. Without it, the command reports the alert's own details and notes that the activity window is unavailable.

When the firewall keeps applying a decision to a particular client rather than a single request, that decision is a persistent action: a challenge or denial that stays in force against an IP and hostname pair for a period. These are read-only and require a team scope.

Aliases: ls.

List persistent actions in a window, newest first, with a summary of what is currently in force. Actions still being applied show Ongoing in place of an end time, because their recorded end is a projected expiry rather than a time they stopped.

vercel firewall persistent-actions list

Options:

• --json: Output as JSON
• --project <name-or-id>: Project name or ID, defaulting to the linked project
• --since <time>: Start of the window, relative (1h, 6h) or an ISO date. Defaults to one hour ago
• --until <time>: End of the window. Defaults to now
• --limit <number>: Number of actions to show. Defaults to 10

Examples:

# List actions from the last hour
vercel firewall persistent-actions list
 
# Widen the window and show more rows
vercel firewall persistent-actions list --since 6h --limit 50

Show one persistent action for an IP: its window, the rule kind and mitigation applied, and the traffic from that client broken down by action.

vercel firewall persistent-actions inspect <ip>

Options:

• --json: Output as JSON
• --project <name-or-id>: Project name or ID, defaulting to the linked project
• --host <hostname>: Narrow to a hostname
• --action <action>: Narrow to a mitigation, such as challenge or deny
• --since <time>: Start of the window to search for the action. Defaults to one hour ago
• --until <time>: End of the window. Defaults to now
• --paths: Include the top request paths

Examples:

# Inspect the most recent action for an IP
vercel firewall persistent-actions inspect 51.158.168.18
 
# Pick one of several actions for the same IP
vercel firewall persistent-actions inspect 51.158.168.18 --host vercel.com --action challenge
 
# Include the paths the client requested
vercel firewall persistent-actions inspect 51.158.168.18 --paths

When an IP has more than one matching action, the most recent is shown and the others are noted. Use --host, --action, --since, and --until to select a specific one. The chart covers the action's own window, so a recent action charts on any plan. An action older than your firewall retention needs Observability Plus.

Custom rules let you define traffic policies based on request attributes. Use them to block abusive traffic, rate limit APIs, challenge suspicious requests, redirect legacy paths, or log traffic for monitoring. Rule changes are staged as drafts and require publishing.

Aliases: ls.

List managed bot rules, then custom firewall rules, including any unpublished draft changes. Draft additions, removals, and modifications are annotated in the output. Managed bot rules appear only on a project. --team-level lists custom rules alone.

vercel firewall rules list

Options:

• -e, --expand: Show full condition and action details for each rule
• --json: Output as JSON

Examples:

# List all rules
vercel firewall rules list
 
# Show full details
vercel firewall rules list --expand

Show a custom rule or a managed bot rule. Custom rules include conditions, action, and rate limit settings. Managed bot rules show the current action and IDs.

vercel firewall rules inspect <name-or-id>

Options:

• --json: Output as JSON

Examples:

# Inspect by name
vercel firewall rules inspect "Block bots"
 
# Inspect by ID
vercel firewall rules inspect rule_abc123
 
# Inspect a managed bot rule
vercel firewall rules inspect bot-protection

Create a new custom firewall rule. You can create rules using four modes: AI (natural language), interactive wizard, command-line flags, or a JSON payload.

vercel firewall rules add [name] [options]

Options:

• --ai <PROMPT>: Generate a rule from natural language (interactive only)
• --json <PAYLOAD>: Create a rule from a full JSON payload
• --condition <JSON>: Add a condition as a JSON object (repeatable). Multiple conditions are combined with AND
• --or: Start a new OR group. Conditions before --or are combined with AND, conditions after form a separate group
• --action <TYPE>: Action: deny, challenge, log, bypass, rate_limit, redirect
• --duration <DURATION>: Action duration: 1m, 5m, 15m, 30m, 1h
• --description <TEXT>: Rule description (max 256 characters)
• --disabled: Create the rule in a disabled state
• --rate-limit-window <SECONDS>: Rate limit time window in seconds, 10 to 3,600 (required for rate_limit)
• --rate-limit-requests <NUMBER>: Max requests per window, 1 to 10,000,000 (required for rate_limit)
• --rate-limit-keys <KEY>: What to count by: ip (default), ja4, header:<name> (repeatable)
• --rate-limit-algo <ALGO>: Algorithm: fixed_window (default), token_bucket
• --rate-limit-action <ACTION>: Action when limit is exceeded: rate_limit (default), deny, challenge, log
• --redirect-url <URL>: Redirect destination URL or path
• --redirect-permanent: Use permanent redirect (301). Default: temporary (307)
• -y, --yes: Skip the confirmation prompt

Examples:

# Interactive mode
vercel firewall rules add
 
# Generate with AI
vercel firewall rules add --ai "Rate limit /api to 100 requests per minute by IP"
 
# Create with flags
vercel firewall rules add "Block bots" \
  --condition '{"type":"user_agent","op":"sub","value":"crawler"}' \
  --action deny --yes
 
# Multiple conditions (AND)
vercel firewall rules add "Secure admin" \
  --condition '{"type":"path","op":"pre","value":"/admin"}' \
  --condition '{"type":"geo_country","op":"neq","value":"US"}' \
  --action deny --yes
 
# OR groups
vercel firewall rules add "Block methods" \
  --condition '{"type":"method","op":"eq","value":"DELETE"}' \
  --or \
  --condition '{"type":"method","op":"eq","value":"PATCH"}' \
  --action challenge --yes
 
# Rate limit
vercel firewall rules add "Rate limit API" \
  --condition '{"type":"path","op":"pre","value":"/api"}' \
  --action rate_limit \
  --rate-limit-window 60 \
  --rate-limit-requests 100 \
  --rate-limit-keys ip \
  --rate-limit-action deny --yes
 
# Redirect
vercel firewall rules add "Redirect old path" \
  --condition '{"type":"path","op":"eq","value":"/old"}' \
  --action redirect \
  --redirect-url "/new" \
  --redirect-permanent --yes
 
# Create from JSON
vercel firewall rules add --json '{"name":"Block bots","conditionGroup":[{"conditions":[{"type":"user_agent","op":"sub","value":"crawler"}]}],"action":{"mitigate":{"action":"deny"}}}' --yes

Each --condition flag takes a JSON object with a type, op, and usually a value:

# Block POST requests to /api
vercel firewall rules add "Block POST to API" \
  --condition '{"type":"path","op":"pre","value":"/api"}' \
  --condition '{"type":"method","op":"eq","value":"POST"}' \
  --action deny --yes

For header, cookie, and query types, include a key field to specify which header, cookie, or query parameter to check. Use neg: true to negate a condition:

# Challenge requests without an Authorization header
vercel firewall rules add "Require auth" \
  --condition '{"type":"header","op":"ex","key":"Authorization","neg":true}' \
  --action challenge --yes

Conditions within a group are combined with AND. Use --or between conditions to create separate groups that are combined with OR.

Edit an existing custom firewall rule, or change the action on a managed bot rule. Custom rules accept AI, an interactive editor, command-line flags, or a JSON payload. Managed bot rules accept --action only.

vercel firewall rules edit <name-or-id> [options]

Options:

• --ai <PROMPT>: Describe changes using natural language (interactive only)
• --json <PAYLOAD>: Replace the rule with a full JSON payload
• --condition <JSON>: Replace conditions (repeatable, same format as add)
• --or: Start a new OR group
• --name <NAME>: Rename the rule
• --action <TYPE>: Change action: deny, challenge, log, bypass, rate_limit, redirect
• --duration <DURATION>: Change action duration
• --description <TEXT>: Change description (use "" to clear)
• --enabled: Set the rule to enabled (mutually exclusive with --disabled)
• --disabled: Set the rule to disabled (mutually exclusive with --enabled)
• --rate-limit-window, --rate-limit-requests, --rate-limit-keys, --rate-limit-algo, --rate-limit-action: Rate limit options (same as rules add)
• --redirect-url, --redirect-permanent: Redirect options (same as rules add)
• -y, --yes: Skip the confirmation prompt

Examples:

# Interactive mode
vercel firewall rules edit "My Rule"
 
# Edit with AI
vercel firewall rules edit "My Rule" --ai "Change action to challenge"
 
# Change action
vercel firewall rules edit "My Rule" --action challenge --duration 5m --yes
 
# Rename
vercel firewall rules edit "My Rule" --name "New Name" --yes
 
# Replace conditions
vercel firewall rules edit "My Rule" \
  --condition '{"type":"path","op":"pre","value":"/new"}' --yes
 
# Change a managed bot rule action
vercel firewall rules edit ai-bots --action deny --yes

Enable a disabled custom firewall rule. Stages a draft change that you must publish.

vercel firewall rules enable <name-or-id>

Options:

• -y, --yes: Skip the confirmation prompt

Disable a custom firewall rule without removing it from your firewall configuration. The rule stops matching requests after you publish the staged changes.

vercel firewall rules disable <name-or-id>

Options:

• -y, --yes: Skip the confirmation prompt

Aliases: rm, delete.

Remove a custom firewall rule. Stages a draft change that you must publish.

vercel firewall rules remove <name-or-id> --yes

Options:

• -y, --yes: Skip the confirmation prompt

Aliases: move.

Change the priority order of a custom firewall rule. Rules are evaluated in order from first to last, so position controls which rules match first. Stages a draft change that you must publish.

vercel firewall rules reorder <name-or-id> [options]

Options:

Pass exactly one of --position, --first, or --last.

• --position <NUMBER>: Target position (1-based)
• --first: Move to the first position (highest priority)
• --last: Move to the last position (lowest priority)
• -y, --yes: Skip the confirmation prompt

Examples:

# Move to first position
vercel firewall rules reorder "My Rule" --first --yes
 
# Move to position 3
vercel firewall rules reorder "My Rule" --position 3 --yes

Bot Protection, AI Bots, and BotID are reserved managed rules. They appear at the top of rules list and in bot-management. They are project-only. --team-level has no managed bot settings.

Action changes are staged as drafts and require publishing. rules add, remove, enable, disable, and reorder refuse these slugs. Change the action with rules edit --action instead.

List the three managed bot rules and the top unknown bot categories over the last 24 hours, matching the Bot Management card in the dashboard.

vercel firewall bot-management

The command prints the current action for each rule, then unknown bot traffic:

  Managed

  Name             Action      ID
  Bot Protection   Challenge   bot-protection
  AI Bots          Allow       ai-bots
  BotID            Basic       bot-id

  Unknown Bot Traffic
  ai_scraper          1.2k
  headless_chrome     800

  Next steps:
  Change Bot Protection
  vercel firewall rules edit bot-protection --action log
  Change AI Bots
  vercel firewall rules edit ai-bots --action deny
  Change BotID
  vercel firewall rules edit bot-id --action deep-analysis
  Break unknown bot traffic down further
  vercel firewall traffic inspect unknown-bot <category>

Unknown bot traffic is team-scoped and reads request counts rather than the firewall metric, so it needs Observability Plus. Without it, the managed rules still print and the unknown-bot panel notes that Observability Plus is required. Without a team scope, the command reports the managed rules on their own.

Drill into a category with vercel firewall traffic inspect unknown-bot <category>.

Options:

• --json: Output as JSON, including { managed, unknownBotTraffic }
• --project <name-or-id>: Project name or ID, defaulting to the linked project

Examples:

# List managed bot rules and unknown bot traffic
vercel firewall bot-management
 
# Report the same data as JSON
vercel firewall bot-management --json
 
# Change AI Bots to deny, then publish
vercel firewall rules edit ai-bots --action deny --yes
vercel firewall publish --yes

Inspect also accepts the WAF id that traffic reports, such as managed_bot_protection. BotID Deep Analysis is not available on Hobby.

IP blocking lets you block specific IP addresses or CIDR ranges from accessing your project. Use it for known malicious IPs, abuse sources, or to restrict access to specific networks. IP block changes are staged as drafts and require publishing.

Aliases: ls.

List all IP blocking rules, including any unpublished draft changes.

vercel firewall ip-blocks list

Options:

• --json: Output as JSON

Block an IP address or CIDR range from accessing your project. Stages a draft change that you must publish.

vercel firewall ip-blocks block <ip> [options]

Options:

• --hostname <HOST>: Scope the block to a specific hostname (default: all hosts)
• --notes <TEXT>: Add a note to the block rule
• -y, --yes: Skip the confirmation prompt

Examples:

# Block an IP
vercel firewall ip-blocks block 1.2.3.4 --yes
 
# Block a CIDR range with a note
vercel firewall ip-blocks block 10.0.0.0/24 --notes "Abuse range" --yes
 
# Block scoped to a hostname
vercel firewall ip-blocks block 1.2.3.4 --hostname example.com --yes

Aliases: rm. The rm alias maps to unblock, not to a generic remove command; for example, vercel firewall ip-blocks rm 1.2.3.4 unblocks that IP.

Remove an IP blocking rule to allow the address to access your project again. Stages a draft change that you must publish.

vercel firewall ip-blocks unblock <id-or-ip> [options]

Options:

• --hostname <HOST>: Narrow the match to a specific hostname (when the same IP is blocked on multiple hosts)
• -y, --yes: Skip the confirmation prompt

Examples:

# Unblock by IP
vercel firewall ip-blocks unblock 1.2.3.4 --yes
 
# Unblock scoped to a hostname
vercel firewall ip-blocks unblock 1.2.3.4 --hostname example.com --yes
 
# Unblock by rule ID
vercel firewall ip-blocks unblock ip_abc123 --yes

System bypass rules ensure that specific IP addresses or CIDR ranges are not blocked by system-level mitigations (such as automatic DDoS mitigation). Use them when legitimate traffic from proxies or shared networks is incorrectly flagged. These commands take effect immediately without publishing.

Aliases: ls.

List all system bypass rules for IPs that skip system-level mitigations.

vercel firewall system-bypass list

Options:

• --json: Output as JSON

Add a system bypass rule so a specific IP address or CIDR range is not blocked by system-level mitigations. Takes effect immediately without publishing.

vercel firewall system-bypass add <ip> [options]

Options:

• --domain <DOMAIN>: Scope the bypass to a specific domain (default: all domains)
• --notes <TEXT>: Add a note to the bypass rule
• -y, --yes: Skip the confirmation prompt

Examples:

# Bypass for an IP
vercel firewall system-bypass add 10.0.0.1 --yes
 
# Bypass for a CIDR range
vercel firewall system-bypass add 10.0.0.0/24 --yes
 
# Bypass scoped to a domain
vercel firewall system-bypass add 10.0.0.1 --domain example.com --yes
 
# Bypass with wildcard domain
vercel firewall system-bypass add 10.0.0.1 --domain "*.example.com" --yes

Aliases: rm.

Remove a system bypass rule so the IP is no longer exempt from system-level mitigations. Takes effect immediately without publishing.

vercel firewall system-bypass remove <ip> [options]

Options:

• --domain <DOMAIN>: Scope the removal to a specific domain
• -y, --yes: Skip the confirmation prompt

Attack Mode adds protection during targeted attacks: visitors must complete a security challenge before accessing your site, while known legitimate bots (for example search crawlers and many webhook providers) are allowed through without a challenge. These commands take effect immediately without publishing.

Enable Attack Mode for your project.

vercel firewall attack-mode enable [options]

Options:

• --duration <DURATION>: How long to keep attack mode active: 1h (default), 6h, or 24h
• -y, --yes: Skip the confirmation prompt

Examples:

# Enable for 1 hour (default)
vercel firewall attack-mode enable --yes
 
# Enable for 24 hours
vercel firewall attack-mode enable --duration 24h --yes

Disable Attack Mode so visitors are no longer challenged at the edge (subject to your custom rules and other firewall layers).

vercel firewall attack-mode disable --yes

Options:

• -y, --yes: Skip the confirmation prompt

Vercel automatically mitigates DDoS attacks and filters malicious traffic. In rare cases, you may need to temporarily pause these protections for debugging, as described in Bypass System-level Mitigations. These commands take effect immediately without publishing.

Pause automatic DDoS protection and system-level traffic filtering for 24 hours. Mitigations automatically resume after 24 hours unless you run resume sooner.

vercel firewall system-mitigations pause --yes

Options:

• -y, --yes: Skip the confirmation prompt

Resume automatic DDoS protection and system-level traffic filtering.

vercel firewall system-mitigations resume --yes

Options:

• -y, --yes: Skip the confirmation prompt

When you add, edit, or remove custom rules and IP blocks, the CLI stages those updates as drafts first. Drafts do not affect production traffic until you publish them.

# Make changes (they are staged automatically)
vercel firewall rules add "Block bots" \
  --condition '{"type":"user_agent","op":"sub","value":"crawler"}' \
  --action deny --yes
 
# Review staged changes
vercel firewall diff
 
# Publish to production
vercel firewall publish --yes

To discard staged changes without publishing, run vercel firewall discard --yes.

System bypass, Attack Mode, and system mitigations take effect immediately and do not require publishing.

Use these commands to review and publish draft changes:

Review draft changes before publishing to production. Shows what was added, removed, modified, enabled, or disabled, with field-level details for modified rules.

vercel firewall diff

Options:

• --json: Output as JSON

Publish all staged firewall changes to production.

vercel firewall publish --yes

Options:

• -y, --yes: Skip the confirmation prompt

Discard all unpublished draft changes, and revert to the current production configuration.

vercel firewall discard --yes

Options:

• -y, --yes: Skip the confirmation prompt

The tables below mirror the Rule configuration reference for custom rules. Use them with the --condition and --action flags in rules add and rules edit.

Each condition specifies a type, an op (operator), and usually a value.

The --duration option makes the action persistent for the matched client. For example, a deny with --duration 30m blocks the client for 30 minutes after the first match, rather than evaluating the rule on every request.

The following global options can be passed when using the vercel firewall command:

• --cwd
• --debug
• --global-config
• --help
• --local-config
• --no-color
• --non-interactive
• --scope
• --team
• --token
• --version

For more information on global options and their usage, refer to the options section.

• Vercel Firewall overview
• Rule configuration reference
• Custom rules
• Bot Management
• BotID
• IP blocking
• Rate limiting
• System bypass rules
• Attack Mode
• DDoS mitigation