Documentation
Docs
Introduction
Getting Started
Tutorial: build an app
Core Concepts
Routing
Server-Side Rendering
Mimir, state management
Pages & Layouts
API Routes
Styling & Theming
Building & Deploying
API Reference
Guides
Recipes
FAQ (use cases)
rateLimit()
Throttle requests per client IP in a sliding window, and reject the ones over the limit with 429.
Use case
Login, signup, password-reset, and write endpoints are brute-force and abuse magnets. A rate limit caps how many requests a single client can make in a window, which blunts credential stuffing, scraping, and accidental request storms, without you tracking anything by hand.
How it works
It keeps a per-IP counter in memory (a null-prototype map, so a crafted IP string cannot poison it). Each
request increments the count for the current window; when the count exceeds max, it replies
429 Too Many Requests and stops. On every allowed request it sets X-RateLimit-Limit and
X-RateLimit-Remaining so well-behaved clients can back off before they are blocked.
Configuration
| Option | Default | Notes |
|---|---|---|
max | 100 | Max requests per window. |
window | 60000 | Window length in ms. |
message | "Too many requests" | The 429 body's error field. |
Example
For a tighter limit on a sensitive endpoint, prefer a per-route limit so a generous global limit and a strict login limit can coexist:
Notes
The counter is per-IP and per-process (in-memory). For multi-process or multi-host deployments each instance counts independently, set the limit accordingly, or front it with a shared limiter at the proxy for a global ceiling. Behind a proxy, make sure
req.ipis the real client IP, not the proxy's.
Next: bodyLimit.