Upstash

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me the cache and queue I actually need instead of Upstash: something my edge functions can reach over HTTP, without a per-request bill.

Read this first: what the fee buys is genuinely useful — an HTTP interface, so a runtime that cannot hold a TCP connection can still use a key-value store, per-request billing so an idle project costs nothing, and replication across regions. If your application runs entirely on edge functions in many regions, that is hard to replace and probably worth paying for. If it runs on one machine, or if you can put one small process near it, this is an afternoon.

STACK
- Valkey or Redis in a container on the same machine as the application, or on a private network beside it
- Node 20+ with Fastify for a thin HTTP layer, only if something genuinely cannot open a TCP connection
- Caddy in front of the HTTP layer, and nothing exposed otherwise

THE FIRST QUESTION
- Do you need a separate key-value store at all? If the application is one process on one machine, an in-process cache with a size limit is faster than any network round trip and needs nothing running
- If you need it shared between processes, or to survive a restart, then run one. If you already have SQLite, it will handle a queue and a rate limiter perfectly well up to a surprising volume
- Reach for a dedicated store when you actually need its data structures — sorted sets, expiring keys at volume, pub/sub — not because it is what one does

RUNNING IT
- One container, bound to localhost or a private network. Never a public interface: an open key-value store is found by a scanner within the hour and is a well-known route into a machine
- A password, and a rename or disabling of the administrative commands
- A memory limit with an eviction policy chosen deliberately — evicting least-recently-used keys is right for a cache and catastrophic for a queue. If both live in the same instance, use separate databases or separate instances, and say why
- Persistence: append-only file for anything that must survive a restart, or none at all for a pure cache. Decide per use, and write the decision down
- A health check and a restart policy

THE HTTP LAYER, IF YOU NEED ONE
- A small service exposing exactly the operations your application uses: get, set with an expiry, increment, delete, and the queue and rate-limit endpoints below
- Not a general command proxy. Exposing arbitrary commands over HTTP is exposing the store itself, and the allow-list is the security boundary
- Token authentication per application, with scopes and a key prefix per token so one service cannot read another's keys
- Rate limited, with a request size cap and a timeout
- Pipelining: accept a batch of operations in one request, because a round trip from an edge function is the cost you are trying to amortise
- Keep it thin. Every feature added here is a feature to secure

WHAT IT IS ACTUALLY USED FOR
- A cache: get, set with a time to live, and a stampede guard so a thousand simultaneous misses do not all recompute the same value
- A rate limiter: a sliding window or a token bucket, implemented as a single atomic script so it is correct under concurrency. A rate limiter with a read-then-write race is not a rate limiter
- A queue: a list or a stream with a consumer group, an acknowledgement, a visibility timeout so a crashed worker's message is redelivered, and a dead-letter list after a retry limit
- A lock: a key set only if absent, with an expiry and a random token checked on release, so a slow holder cannot release somebody else's lock. Write it correctly or use a library that already has
- Sessions, which mostly do not need this — a signed cookie or a database row is simpler and survives a restart

REGIONS
- If the application is genuinely in several regions, this is where the honest answer is to pay somebody. Replicating a key-value store across continents with sensible consistency is not an afternoon
- If it is one region with users everywhere, put the cache next to the application, not next to the users. The database round trip is what you are saving, and that is local either way

WATCHING IT
- Memory used against the limit, eviction rate, hit rate, connected clients, and the slow log
- Queue depth and the age of the oldest unacknowledged message, which is the number that tells you a consumer has died
- Alert on eviction in an instance that holds a queue, because that means data was silently dropped

OPERATIONS
- .env: REDIS_URL, HTTP_TOKENS, BASE_URL, MAX_REQUEST_BYTES
- Backups only for the instances holding something that matters; a cache needs none, and saying which is which is part of the design
- Health endpoint that sets, reads and deletes a key

WHAT MATTERS MOST
The allow-list and the eviction policy. Expose only the operations you use, and never let a queue live in an instance that evicts. Then check whether you needed a separate store at all — the cheapest cache is the one already inside the process.

Give me the compose file, the HTTP layer, the atomic scripts for rate limiting and locking, the queue helpers, .env.example, and a README that opens with the question of whether you need this at all.