---
kind: task
slug: distribute-rate-limit-redis-backed
title: Move rate-limit storage from in-memory to Redis
plan_slug: multitenant-saas-hardening
epic_slug: tenant-lifecycle
status: draft
priority: P3
tenant_id: global
owner: unassigned
cursor_todo_id: null
updated_at: "2026-06-02"
---

# Task summary

`apps/web/server/lib/rate-limit.ts` uses an in-process `Map`. That works fine for a single pod but trips break the moment we scale horizontally — every pod has its own bucket, and an attacker rotating across them effectively gets `N × limit` attempts.

Swap the backing store to Redis (already deployed for Hocuspocus on CT 102) without changing the `rateLimit()` API surface.

## Subtasks

- [ ] Decide on the lib: `@upstash/ratelimit` works against any Redis URL despite the name, or hand-roll a sliding-window in `ioredis`. The token-bucket primitive in `packages/shared/src/utils/token-bucket.ts` is fine to keep as a pure-logic reference for tests.
- [ ] Add a `REDIS_URL` env to `apps/web` (it already exists for `apps/collab-server`; just plumb it).
- [ ] Implement the Redis-backed `rateLimit()` alongside the in-memory one. Feature-flag the swap behind `RATE_LIMIT_BACKEND=redis` so the rollback is one env edit.
- [ ] Add an integration test that brings up Redis in CI (or skip on absence) and verifies the bucket survives a process restart simulation.

## Acceptance criteria

- [ ] `pnpm --filter @tasks/web build` succeeds with the Redis backend selected.
- [ ] Two `apps/web` processes pointed at the same Redis share a single bucket per key.
- [ ] In-memory fallback still works when `RATE_LIMIT_BACKEND=memory` (default).

## Links

- Parent: `./Task-rate-limit-and-abuse-guardrails.md`
- Epic: `./Epic-tenant-lifecycle.md`