Configure Upstash Ratelimit Strapi Plugin
After setting up the plugin, it’s possible to customize the ratelimiter algorithm and rates. You can also define different rate limits and rate limit algorithms for different routes.
General Configurations
Enable or disable the plugin.
Database Configurations
The token to authenticate with the Upstash Redis REST API. You can find this
credential on Upstash Console with the name UPSTASH_REDIS_REST_TOKEN
The URL for the Upstash Redis REST API. You can find this credential on
Upstash Console with the name UPSTASH_REDIS_REST_URL
The prefix for the rate limit keys. The plugin uses this prefix to store the
rate limit data in Redis.
For example, if the prefix is @strapi, the key will be
@strapi:<method>:<route>:<identifier>.
Enable analytics for the rate limit. When enabled, the plugin extra insights related to your ratelimits. You can use this data to analyze the rate limit usage on Upstash Console.
Strategy
The plugin uses a strategy array to define the rate limits per route. Each strategy object has the following properties:
An array of HTTP methods to apply the rate limit.
For example, ["GET", "POST"]
The path to apply the rate limit. You can use wildcards to match multiple
routes. For example, * matches all routes.
Some examples:
path: "/api/restaurants/:id"path: "/api/restaurants"
The source to identifiy the user. Requests with the same identifier will be
rate limited under the same limit.
Available sources are:
ip: The IP address of the user.header: The value of a header key. You should pass the source in theheader.<HEADER_KEY>format.
For example,header.Authorizationwill use the value of theAuthorization
Enable debug mode for the route. When enabled, the plugin logs the remaining
limits and the block status for each request.
The limiter configuration for the route. The limiter object has the following properties:
The rate limit algorithm to use. For more information related to algorithms, see docs here.
fixed-window: The fixed-window algorithm divides time into fixed intervals. Each interval has a set limit of allowed requests. When a new interval starts, the count resets.sliding-window: The sliding-window algorithm uses a rolling time frame. It considers requests from the past X time units, continuously moving forward. This provides a smoother distribution of requests over time.token-bucket: The token-bucket algorithm uses a bucket that fills with tokens at a steady rate. Each request consumes a token. If the bucket is empty, requests are denied. This allows for bursts of traffic while maintaining a long-term rate limit.
The number of tokens allowed in the time window.
The time window for the rate limit. Available units are "ms" | "s" | "m" | "h" | "d"
For example, 20s means 20 seconds.
The rate at which the bucket refills. This property is only used for the token-bucket algorithm.
Examples
Was this page helpful?