Query Upstash Redis over HTTPS in serverless environments

Upstash Redis teaches use of @upstash/redis, a TypeScript client that sends Redis commands to an Upstash database over HTTPS. Each command is a stateless HTTP request, avoiding the persistent TCP connection and pooling requirements of traditional clients. JavaScript values are automatically serialized and deserialized, so objects and numbers can round-trip without manual JSON parsing. Command names appear as lowercase client methods such as get, set, hset, zadd, and incr.

The skill covers cache-aside reads, TTL-based cache entries, invalidation, counters, hashes, sorted-set leaderboards, and batched commands. Its cache example reads a user key, fetches missing data from a database, stores it with a one-hour expiry, and deletes the key when invalidation is needed. A pipeline example groups independent hash, counter, and leaderboard updates into one network round trip.

Use this skill when a serverless or edge function needs a cache, session store, counter, leaderboard, or simple queue. It also applies when migrating an ioredis or node-redis call site to a runtime that cannot maintain a TCP socket. Supported environments include Vercel and Netlify functions, Cloudflare Workers, Deno, Bun, and Next.js middleware.

The client speaks the Upstash REST protocol and cannot connect to self-hosted or other non-Upstash Redis servers. It is not a Redis administration or CLI workflow, and this skill covers the TypeScript client rather than Python, Go, or other SDK method names. HTTP commands add latency compared with a warm TCP connection, so batching matters where repeated round trips would be costly. Environment-specific validation and testing are still required.

Configuration begins with an Upstash database and its REST URL and token stored in environment variables or a secrets manager. Credentials must not be hardcoded. Create one client per module using:

export const redis = Redis.fromEnv();

Cloudflare Workers use the cloudflare package entrypoint and pass the worker environment to Redis.fromEnv. Calls accept and return native JavaScript types. Cache keys should use readable namespaces and explicit TTLs so stale entries expire. Passing JSON.stringify output to set is unnecessary and can cause an incremented number to return as a string; store the raw number and let the client serialize it. A production-only null result should prompt checking the deployed REST environment settings.

Pipeline batches independent commands but is not atomic. Use multi for MULTI/EXEC or a reviewed server-side Lua script when operations must execute as one unit. Transactions do not roll back runtime errors, and WATCH is unavailable over REST; atomic check-and-set requires Lua. Pub/Sub subscription and blocking operations such as BLPOP and XREAD BLOCK are unsupported.

The integration is the Upstash Redis HTTPS service and its TypeScript client. Use pipeline, mget, or mset instead of many sequential awaits, and scan instead of wildcard keys in handlers for large keyspaces. Tokens remain server-side because they grant database read/write access; read-only workloads should use a read-only token. Secrets or personal data require a retention plan and TTL. Destructive production commands, including flushdb and del, require confirmation.