Use Rate Limiting in a real application path
Rate Limiting bindings let Workers enforce fixed-window limits from inside application code.
A compact Rate Limiting recipe with config and worker usage in one application path.
Use this as the copyable starter before threading the feature into a larger application.
- Config focus
- bindings.rateLimits
- Runtime shape
- Best use
- login throttles, per-user limits, and API guardrails that can use Cloudflare fixed windows
Start by wiring the binding clearly in config
Smallest Rate Limiting config
Build the application flow around the binding
Treat this as the app-level Rate Limiting path: the route, event handler, or service module receives a real request and uses the binding to do useful work.
Keep product limits, remote ownership, and fallback behavior visible in the code around the binding instead of hiding everything behind a vague utility too early.
- Keep the first example short enough to paste into a new Worker.
Use the limiter in a request path
Keep production boundaries visible
- Config focus: bindings.rateLimits.
- Runtime shape: .
- Best use: login throttles, per-user limits, and API guardrails that can use Cloudflare fixed windows.
Thread this into the next recipe
Once this smallest path works, add routing, generated types, and feature-specific abstraction in that order.
Previous
Testing Rate Limiting
Test Rate Limiting by choosing the local harness that matches the product boundary instead of reaching for Cloudflare by default.
Next
Version Metadata
Add the Version Metadata config, call from worker code, and start with the local test path Devflare supports.