Rate limiting

Rate limiting lets you control the number of requests to your project or specific paths.

Basic functionality is available on all plans.
Full functionality is available on Enterprise plans with High-Performance Edge. Learn more.

Use cases

Rate limiting is useful for:

• Mitigating DDoS attacks beyond our built-in default protections.
• Protecting backend services: Server-side code often fetches data from your database, CMS, or backend APIs, or calls an AI provider to make inference requests. A traffic spike can cause requests made from server-side code to your backend services to hit rate limits or rack up excessive costs.
• Preventing excessive scraping and bot traffic and the associated bandwidth usage.
• Enforcing fair API usage by your visitors.

You can configure what action is taken when rate limiting is applied to a request:

• Block the request (returns HTTP status 429), or:
• Rewrite the request to another path (e.g. /rate_limit_page.html)

Rate limiting is applied after DDoS protection, firewall traffic rules, and WAF rules. Only requests that have passed all these security mechanisms are counted. Learn more.

Use rate limiting with the AI Gateway

Netlify’s AI Gateway lowers the barrier to using AI in your web apps. The gateway comes with built-in account-level rate limits for Requests Per Minute (RPM) and Tokens Per Minute (TPM).

However, if specific clients use your AI features excessively, this could generate high AI inference costs over time, or trigger the rate limits of the AI Gateway - potentially impacting legitimate user activity.

Setting rate limits on functions that call the AI Gateway helps prevent these risks by throttling any given client’s usage to a desired limit. Learn more.

Code-based vs. UI-based rules

Customers in all plans can programmatically apply limits to specific functions, edge functions, or redirects, by adding rules in code.

Enterprise customers with high-performance edge can also create [advanced rules(#add-rules-in-the-ui) via the UI and apply these at the team or project level.

	Code-based rules	UI-based rules
Availability	All plans	Only for Enterprise with HP Edge
Best for	Testing rules with a PR or branch preview, then merging to production.	Enforcing team-wide policies across all new and existing projects.
Targeting conditions	By path only	By path, client IP ranges, geolocation, cookie, or HTTP header.
Controlling published vs. unpublished deploys	Via branches in source control	Via UI settings
Tracking changes	Via source control	Via the team audit log

You can use both code-based and UI-based rules in a given project. In such a case, code-based rules take precedence.

Request aggregation options

Netlify supports two methods for counting requests, or aggregation modes. These modes are available both in code-based and UI-based rules.

• Per domain and IP address: Each visitor is limited to a specified number of requests per time duration (60 seconds by default). This option is good for stopping bad actors and available to all customers. However, note that it does not enforce an absolute limit across all visitors.

• Per domain: (Available only for enterprise customers with high-performance edge) Traffic across all visitors is limited to a shared number of requests per time duration. Netlify ensures a fair allocation of requests across clients. This option is good for protecting your backend services no matter how many visitors are visiting your site.

How per-domain aggregation works

Here’s what happens if you set a limit of 300 requests per domain:

1. Once that limit is reached for the domain, we ban the IP address with the highest request rate first.

2. We then adjust the currently counted requests to reduce the amount of traffic just banned, so all other clients can use the full limit of 300 requests.

3. If the actual request rate is still over 300 requests, we repeat the process.

Netlify assigns a weight to IP addresses based on both the number of requests and how recently these requests were made. In this way, we prioritize limiting the clients that are currently generating the largest amount of traffic - until the desired limit is reached.

Note: for the example scenario above, you may notice more than 300 requests for a short time interval until all high-rate IPs are banned and the target rate is reached.

Add rules in code

All plans support rate limiting rules in code for serverless functions, edge functions, and redirects.

This is especially useful for protecting paths that call external APIs — preventing excessive requests, high costs, or degradation of downstream services.

Set limits for functions

Limits for Netlify functions and edge functions are defined in the exported config object of your function file.

You must also have a path for the function defined in this object (see reference for serverless functions and edge functions).

Edge function example

import type { Config, Context } from "@netlify/edge-functions";

// use-case: safeguarding your edge function usage/spend
export default async (request: Request, context: Context) => {
  // This edge function might call e.g. a database, a CMS, an LLM, or other
  // 1st-party or 3rd-party API
};

// to block more than 100 requests for this path in 60 seconds, per IP:
export const config: Config = {
  path: "/",
  rateLimit: {
    windowLimit: 100,
    windowSize: 60,
    aggregateBy: ["ip", "domain"],
  }
};

// OR ALTERNATIVELY, to rewrite requests above the limit to a dedicated page
// (instead of returning status code 429)
export const config: Config = {
  path: "/",
  rateLimit: {
    action: "rewrite",
    to: "/custom_rate_limit.html", // rewrite target
    windowLimit: 100,
    windowSize: 120, // in seconds. Maximum is 180.
    // enterprise feature: enforce fair shared limit between all clients
    aggregateBy: ["domain"],
  }
};

Serverless function example

import type { Config, Context } from "@netlify/functions"

// use-case: safeguarding your serverless function usage/spend
export default async (request: Request, context: Context) => {
  // This function might call e.g. a database, a CMS, an LLM, or other
  // 1st-party or 3rd-party API
};

export const config: Config = {
  path: "/",
  rateLimit: {
    windowLimit: 100,
    windowSize: 60,
    aggregateBy: ["ip", "domain"],
  }
};

Note: rate limits for functions cannot be defined in the netlify.toml configuration file.

Set limits for redirects

Programmatic rate limiting is supported for redirects defined in netlify.toml (see reference to redirects).

Here are two cases where redirect-based rate limiting is useful:

Protect calls to an external API

If your client-side is directly calling API services external to Netlify, and you rather not wrap that API in a Netlify function or edge function, you can still use Netlify to rate-limit these calls.

Here’s how to protect the external API https://api.mysearch.com via a proxy path /search on your Netlify site.

# In your netlify.toml file

[[redirects]]
  from = "/search" # Netlify-managed redirect, acting as proxy to:
  to = "https://api.mysearch.com" # External API vulnerable to spikes
  status = 200
  force = true
    [redirects.rate_limit]
    # 50 requests per IP per minute
    window_limit = 50
    window_size = 60
    aggregate_by = ["ip", "domain"]

Proxying external services through Netlify is a long-standing pattern used by many customers to gradually migrate services to Netlify, or to abstract calls to their other servers. Rate limit for these proxied paths is an extra benefit of this approach.

Protect your whole site

# In your netlify.toml file

[[redirects]]
  from = "/*"
  to = "/:splat"
    [redirects.rate_limit]
    action = "rewrite" # optional, will default to "rate_limit"
    to = "/custom_rate_limit.html" # only needed if action is "rewrite"
    # 50 requests per minute
    window_limit = 50
    window_size = 60
    # share limit fairly between all clients (note: enterprise-only feature)
    aggregate_by = ["domain"]

Note: rate limits cannot be defined in a _redirects file.

Verify that code-based rules are applied

Netlify reads and validates code-based rate limit rules at the end of each deploy, during the post-processing stage.

If your rules are valid, their details appear in the deploy log under that stage. Invalid rules generate error messages.

In some error cases (for example, due to a syntax error in JavaScript or netlify.toml) Netlify may not detect at all that you’ve attempted to define a rule - and neither an error nor a success message appears. In that case, double-check the rule’s syntax using the documentation on this page.

Note: a rule that does not pass validation does not fail the deploy. When adding or changing rules, it is recommended to always check your deploy log.

Add rules in the UI

In enterprise accounts using High Performance Edge, Team Owners can manage rules visually in the UI, by creating rulesets comprised of one or more rules.

Rulesets can be applied to individual projects or enforced team-wide, for both existing projects and any new ones created afterwards.

When a Team Owner creates, edits, deletes, or applies a rate limiting ruleset in the Netlify UI, these actions are logged in the Team audit log. Rate limit rules are read-only for the Developer role.

Available conditions

UI-based rules go beyond path-based targeting only. A rule defined in the UI can include any logical combination of the following conditions:

Condition	Examples
Client IP address or range, in CIDR notation	155.255.355.0/24 to only rate-limit clients from that range
Geolocation	Country (e.g., United States) or state/sub-region (e.g., California, Crimea)
Cookie (text or regex)	session_key=.* (also targets that cookie with an empty value)
Header (text or regex)	user-agent: heavy-crawler to limit a specific crawler by its user-agent. Learn more in the developer guide. Authorization: Bearer ABUSED_TOKEN in case a specific token was leaked publicly, or is being used for abuse.
Path (text or regex)	/api/v1/.* (for all /api/v1/ endpoints)

Behavior when multiple rules are met

Assume an example ruleset with two rules:

Rule 1: Protect homepage

• Condition: when a request matches the path /index.html
• Limit: 10 requests per minute
• Action: Rewrite to a dedicated error page
• Request aggregation: by domain

Rule 2: Limit known API abusers

• Condition: when a request has the header Authorization: Bearer ABUSIVE-TOKEN.
• Limit: 5 requests per minute
• Action: Block and return a 429 error
• Request aggregation: by domain

What happens when requests match both rules

• If there are 7 such requests per 60 seconds, rule #2 is applied to the requests over the limit (i.e., the 6th and 7th requests). The block action is applied.
• If there are 12 such requests per 60 seconds, then once rule #1 has been met as well (after 10 requests), it applies to the following requests in that time window, since it was defined first in the ruleset. The rewrite action is applied to these requests.

Limitations

The rate limiting feature includes these limits:

• 100 rules maximum per ruleset.
• A maximum of 2 rate limiting rulesets can be set per project — one for published deploys and one for unpublished deploys. You can apply the same ruleset to both or use two different ones.

Manage rulesets in the UI

Rate limiting rules are managed in rulesets, which can be edited and applied to projects. Only Team Owners can create, edit, or delete a ruleset.

Any changes to a ruleset (creating a ruleset, editing it, or deleting it) take effect immediately for all projects where the ruleset applies.

To create a ruleset:

1. Go to Team settings > Access & security > Rate Limiting > Team rulesets.

2. Select Create ruleset.

3. Enter your ruleset name and description.

4. Select Add a rule and follow the prompts. You can add up to 100 rules for a ruleset. When you add a rule, you can specify the following:

   • Rule condition: defines when the rule is triggered. For an overview of your options, check out the rule conditions table.
   • Limit: defines the number of requests allowed per 60 seconds.
   • Request aggregation: defines how we calculate and apply the limit for your rule. Includes Per domain (default) (ideal to protect your backend) or Per domain and IP address (ideal to target a potential bad actor).
   • Action: defines what happens when the rate limit threshold is crossed. The action is applied for 60 seconds. Currently supports these actions:
     • Block: this action blocks access to the project and returns a 429 status code.
     • Rewrite to path: this action rewrites the request path with a new relative path that you specify. For example, you can rewrite requests to your own customized rate limit error page with a relative path such as /rate_limit_page.html.

5. Confirm your rule by selecting Add rule.

6. Optionally, repeat steps 4 and 5 to add more rules to your ruleset as needed.

7. Save your ruleset.

Next, you can make your ruleset the team policy or apply it to an individual project.

Apply a ruleset to a project

Only Team Owners can apply a ruleset to a project from the Project Configuration page in the Netlify UI.

To apply a ruleset to a project:

1. For the desired project, go to Project configuration > Access & security > Rate limiting.

2. Under Rulesets for [site name], select Manage rulesets.

3. Choose a ruleset option to apply to your project’s published deploys and/or unpublished deploys and select Save. If you already have a team policy ruleset configured, then you can override the team policy ruleset with a different ruleset.

Configure a team policy ruleset in the UI

To rate limit your team’s projects with a default ruleset, configure a team policy for your project’s published deploys and/or unpublished deploys.

The team policy ruleset applies to all new and existing projects in your team. A Team Owner can override the team policy ruleset with a different ruleset for one project at a time.

A maximum of 2 rate limiting rulesets can be set per project — one for published deploys and one for unpublished deploys. You can apply the same ruleset to both or use two different ones.

To configure a team policy:

1. Go to Team settings > Access & security > Rate Limiting > Team policy rulesets.

2. Select Configure team policy.

3. Choose a ruleset option for published deploys and/or unpublished deploys, then save your changes.

Availability

• Customers on all plans can use code-based rules. The maximum number of rules allowedper project varies by plan.
• Enterprise customers with high-performance edge: In addition to 100 code-based rules per project, customers on this plan can create rules through the UI at the project or team level. UI-based rules offer extended targeting conditions compared to rules set in code.

Feature	Free (Credit-Based or Legacy) / Starter / Personal	Pro (Credit-Based or Legacy) / Enterprise	Enterprise with HP Edge
Code-based rules	2 per project	5 per project	100 per project
Targeting by path	✓	✓	✓
Block or rewrite requests	✓	✓	✓
UI-based rules	–	–	✓
Advanced targeting	–	–	✓ Target by IP, geolocation, request headers (e.g. user-agent), or cookie. Combine conditions with and/or.
Team-level enforcement	–	–	✓
Aggregation options	Per domain & IP	Per domain & IP	Per-domain, per domain & IP