Open source · built for Node.js

Shape traffic.
Keep breathing.

A focused rate-limiting library with three proven algorithms, atomic Redis coordination, and one API that stays out of your framework.

Read the quickstartExplore algorithms

$npm i limixCopy

3Algorithmsone clean contract

2Storeslocal or shared

1Small APIconsume and decide

traffic monitor

live

72remaining

Current windowHealthy headroom28 of 100 requests consumed

200user_72a14msallow

200tenant_orbit3msallow

429api_91bd2mslimit

Redis connectedfixed-window · 60s

Start in under two minutes

No middleware lock-in and no sprawling configuration surface. Create a limiter, choose where its state lives, and consume against any identifier that matters to your application.

01

Install the package

It ships with types and has no framework opinions.

terminalCopy

$ npm install limix

limit.ts

import {
  Algorithms,
  createRateLimiter,
  MemoryStore,
} from 'limix';

const limiter = createRateLimiter({
  algorithm: Algorithms.FIXED_WINDOW,
  limit: 100,
  windowMs: 60_000,
  store: new MemoryStore(),
});

const decision = await limiter.consume('user_42');

if (!decision.allowed) {
  // Return 429, delay the job, or apply your own policy.
}

The package returns the decision and useful limit metadata. Your transport layer decides what happens next.

Redis coordination

One decision. One atomic operation.

Lua-backed updates keep concurrent requests from slipping through the same opening.

read→decide→write

Portable policy↗

Framework optional.

Use the same limiter in Express, workers, queues, cron jobs, or plain Node.

HTTPjobsworkers

Useful decisions↗

More than yes or no.

allowedtrueremaining72resetAt12:04:00

Pick the pressure valve that fits

Rate limiting is a traffic-shaping decision, not a checkbox. Use the lab to get a feel for how each strategy responds to the same uneven stream.

Traffic lab

See the trade-off, not just the name.

FixedSlidingBucket

limit

A simple counter resets at the edge of each window.

accepted8/10

01

Fixed window

Cheap, direct, and excellent when a boundary burst is acceptable.

Read the guide →02 · balanced

Sliding window

Smoother enforcement around boundaries without storing every request.

Read the guide →03

Token bucket

Built for controlled bursts with capacity that replenishes over time.

Read the guide →

Local first. Distributed when you need it.

Use the memory store for development, tests, and single-process workloads. Move to Redis when several application instances must agree on the same limit.

StoreBest forCoordinationSetup

MemoryBuilt in

Tests, scripts, and a single application process.

Local onlyNo infrastructure →

RedisDistributed

Production APIs, workers, and multiple instances.

Shared stateBring Redis →

Keep policy near the edge

Create the limiter once, then reuse it in middleware, handlers, queues, or service methods. Avoid constructing a new store for every request.

One more thing

Add it to your first route.

Build your first limiter →One package, no dashboard to sign into — you'll be done before the coffee is.