| name | upstash-redis |
| description | Use Redis over HTTP from serverless and edge runtimes with @upstash/redis, and add rate limiting with @upstash/ratelimit. Use when the user mentions Upstash Redis, needs Redis from a Next.js route handler or middleware, Vercel, Cloudflare Workers, Deno, or Bun without TCP connection pooling, or wants cache-aside with TTLs, a session store, counters, or a 429 rate limiter using fixed window, sliding window, or token bucket. DO NOT use for self-hosted or TCP Redis clients (ioredis, node-redis), Redis Cluster administration, or vector similarity search.
|
| license | MIT |
| compatibility | @upstash/redis 1.x, @upstash/ratelimit 2.x, Node.js 18+ or any runtime with global fetch |
| metadata | {"author":"Upstash"} |
Upstash Redis Skill
This skill covers the three things serverless apps most often need Redis for:
caching, sessions, and rate limiting. The client talks to Redis over HTTP, so
it works where a long-lived TCP connection does not (edge middleware, short
lived functions). Follow the steps in order; each ends with a checkpoint.
Requirements and limitations
- An Upstash Redis database (hosted service; usage-based pricing with a free
tier). Credentials are a REST URL and token from the database page.
- Environment variables
UPSTASH_REDIS_REST_URL and UPSTASH_REDIS_REST_TOKEN.
- Every command is an HTTP request. Batch with
pipeline() or MGET/MSET
when you issue many commands per request; avoid KEYS * in production.
- Values are serialized automatically (objects, arrays, numbers round-trip).
Do not
JSON.stringify before set or parseInt after get.
Step 1 — Install and create one client per module
npm install @upstash/redis @upstash/ratelimit
import { Redis } from "@upstash/redis";
export const redis = Redis.fromEnv();
Create the client at module scope, not inside the request handler, so
ephemeral caches and pipelines can be reused across invocations.
Checkpoint: await redis.ping() returns "PONG".
Step 2 — Cache-aside with TTL
import { redis } from "@/lib/redis";
type User = { id: string; name: string; plan: "free" | "pro" };
export async function getUser(userId: string): Promise<User | null> {
const key = `user:${userId}`;
const cached = await redis.get<User>(key);
if (cached) return cached;
const user = await db.users.findById(userId);
if (user) await redis.set(key, user, { ex: 3600 });
return user;
}
export async function updateUser(userId: string, patch: Partial<User>) {
const user = await db..(userId, patch);
redis.(, user, { : });
user;
}
() {
db..(userId);
redis.();
}
Always set a TTL on cache entries; namespace keys (user:123, session:abc).
Checkpoint: second call to getUser returns without hitting the database
and await redis.ttl("user:123") is positive.
Step 3 — Sessions with sliding expiration
import { redis } from "@/lib/redis";
const SESSION_TTL = 60 * 60 * 24;
export async function createSession(userId: string, data: Record<string, unknown>) {
const sessionId = crypto.randomUUID();
await redis.set(`session:${sessionId}`, { userId, ...data, createdAt: Date.now() }, { ex: SESSION_TTL });
return sessionId;
}
export async function getSession<T = Record<string, unknown>>(sessionId: string) {
const session = await redis.get<T>(`session:${sessionId}`);
if (session) await redis.expire(`session:${sessionId}`, SESSION_TTL);
return session;
}
() {
redis.();
}
Store the session id in an HttpOnly; Secure; SameSite cookie; never put the
Redis token in client code.
Checkpoint: getSession after createSession returns the object with
userId; after destroySession it returns null.
Step 4 — Rate limiting a route handler
import { Ratelimit } from "@upstash/ratelimit";
import { Redis } from "@upstash/redis";
const ratelimit = new Ratelimit({
redis: Redis.fromEnv(),
limiter: Ratelimit.slidingWindow(10, "10 s"),
prefix: "ratelimit:search",
});
export async function POST(request: Request) {
const ip = request.headers.get("x-forwarded-for")?.split(",")[0]?.trim() ?? "anonymous";
const { success, limit, remaining, reset } = await ratelimit.limit(ip);
if (!success) {
return new Response("Too Many Requests", {
status: 429,
headers: {
: (limit),
: (remaining),
: (.(, .((reset - .()) / ))),
},
});
}
.({ : });
}
- Identifier: use the user id or API key when authenticated; fall back to IP.
- Algorithms:
Ratelimit.fixedWindow(n, "1 m") (cheapest), slidingWindow
(smooth boundaries, default choice), tokenBucket(refill, "10 s", max)
(allows bursts). Windows accept ms, s, m, h, d.
- Tiers: create one
Ratelimit per tier with different prefix values.
- Edge middleware / Cloudflare Workers with
analytics: true: the result has a
pending promise; pass it to context.waitUntil(pending) so background work
finishes before the runtime exits.
reset is a Unix timestamp in milliseconds.
Checkpoint: the 11th request within 10 seconds returns 429 with a
Retry-After header; after the window it succeeds again.
Common pitfalls
- Creating clients inside handlers: the limiter's in-memory
ephemeralCache only helps when the instance outlives the request.
- Manual JSON:
redis.set("k", JSON.stringify(v)) then redis.get returns
an already-parsed object; double parsing throws.
- No TTL on cache keys: memory grows until eviction; always pass
{ ex }.
- Trusting
x-forwarded-for blindly: take the first hop, or use the
platform's IP helper, when behind a proxy.
- Forgetting
pending on edge runtimes with analytics or multi-region
limiters.
When NOT to use this skill
- Long-running servers with a TCP Redis connection already in place: keep
ioredis/node-redis.
- Vector search or RAG: use a vector database skill instead.
- Sub-millisecond, in-process caching: use an in-memory LRU.
References