Rate limiting middleware for Hono. Use to limit repeated requests to public APIs and/or endpoints such as password reset.

[!NOTE]
The keyGenerator function needs to be defined for hono-rate-limiter to work properly in your environment. Please ensure that you define the keyGenerator function according to the documentation before using the library.

Installation

# Using npm/yarn/pnpm/bun
npm add hono-rate-limiter

Usage

Rest APIs

import { rateLimiter } from "hono-rate-limiter";

const limiter = rateLimiter({
  windowMs: 15 * 60 * 1000, // 15 minutes
  limit: 100, // Limit each IP to 100 requests per `window` (here, per 15 minutes).
  standardHeaders: "draft-6", // draft-6: `RateLimit-*` headers; draft-7: combined `RateLimit` header
  keyGenerator: (c) => "<unique_key>", // Method to generate custom identifiers for clients.
  // store: ... , // Redis, MemoryStore, etc. See below.
});

// Apply the rate limiting middleware to all requests.
app.use(limiter);

WebSocket APIs

import { webSocketLimiter } from "hono-rate-limiter";
import { upgradeWebSocket } from "hono/cloudflare-workers";
import { RedisStore } from "@hono-rate-limiter/redis";
import { Redis } from "@upstash/redis/cloudflare";

const limiter = webSocketLimiter({
  windowMs: 15 * 60 * 1000, // 15 minutes
  limit: 100, // Limit each IP to 100 requests per `window` (here, per 15 minutes).
  keyGenerator: (c) => "<unique_key>", // Method to generate custom identifiers for clients.
  store: new RedisStore({ client }), // Define your DataStore. See below.
});

// Apply the rate limiting middleware to ws requests.
app.get(
  "/",
  upgradeWebSocket(
    limiter((c) => {
      return {
        onOpen: () => {
          console.log("Connection opened");
        },
        async onMessage(event, ws) {
          console.log(`Message from client: ${event.data}`);
          ws.send("Hello from server!");
        },
        onClose: () => {
          console.log("Connection closed");
        },
      };
    })
  )
);

Data Stores

hono-rate-limiter supports external data stores to synchronize hit counts across multiple processes and servers.

By default, MemoryStore is used. This one does not synchronize its state across instances. It’s simple to deploy, and often sufficient for basic abuse prevention, but will be inconnsistent across reboots or in deployments with multiple process or servers.

Deployments requiring more consistently enforced rate limits should use an external store.

Here is a list of stores:

| Name | Description | | ------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | MemoryStore | (default) Simple in-memory option. Does not share state when the app has multiple processes or servers. | | @hono-rate-limiter/redis | A Redis-backed store, used with @vercel/kv and @upstash/redis | | @hono-rate-limiter/cloudflare | A Cloudflare-backed store, used with WorkersKV and Workers Rate Limiting API | | rate-limit-redis | A Redis-backed store, more suitable for large or demanding deployments. | | rate-limit-postgresql | A PostgreSQL-backed store. | | rate-limit-memcached | A Memcached-backed store. | | cluster-memory-store | A memory-store wrapper that shares state across all processes on a single server via the node:cluster module. Does not share state across multiple servers. | | precise-memory-rate-limit | A memory store similar to the built-in one, except that it stores a distinct timestamp for each key. | | typeorm-rate-limit-store | Supports a variety of databases via TypeORM: MySQL, MariaDB, CockroachDB, SQLite, Microsoft SQL Server, Oracle, SAP Hana, and more. | | @rlimit/storage | A distributed rlimit store, ideal for multi-regional deployments. |

Take a look at this guide if you wish to create your own store.

Notes

• The keyGenerator function determines what to limit a request on, it should represent a unique characteristic of a user or class of user that you wish to rate limit. Good choices include API keys in Authorization headers, URL paths or routes, specific query parameters used by your application, and/or user IDs.
• It is not recommended to use IP addresses (since these can be shared by many users in many valid cases) or locations (the same), as you may find yourself unintentionally rate limiting a wider group of users than you intended.

Contributing

We would love to have more contributors involved!

To get started, please read our Contributing Guide.

Credits

The hono-rate-limiter project is heavily inspired by express-rate-limit