Jadpo is experimental and not ready for production. These docs follow the compiler's main branch as of 30 Oct 2026. What's built · Install 0.1.0
jadpo
Reference: Built-in services

Built-in services

Caches: drivers and what they hold

On this page

Nothing is cached unless you add it. Caches says how you add a cache and how its copies stay current. This topic says which services can hold a cache and what a cache may hold.

Redis-compatible services

Upstash, Valkey, Amazon ElastiCache and Redis itself all use the Redis driver, on the native target and on Workers. Each service's settings are listed on the driver's page, as every driver's are (Connecting in app.jadpo).

Driver.memory

Driver.memory keeps a cache in each server's own memory. Each server then has its own cache, emptied on every restart. You may use it in production, and jadpo check warns you when you do. On Workers it is a compile error, because a Worker keeps no memory between requests.

Cloudflare KV

Cloudflare KV isn't a cache driver. A change to KV can take a minute to reach every location, so an entry you invalidated could still be served. An app that wants KV calls it as a package.

What a cache may hold

A cache holds only what is harmless to lose: cached records and query results, route rate limits, and provider rate limits shared across servers. All of them go through the same rate_limits: { store: cache } and caching settings.

A cache never holds idempotency keys, webhook de-duplication, sessions, OAuth grants, poll state, schedule leases, batch positions, the records of a multi-step call or the outbox. Each of those must survive a restart, so each lives in a database. Naming a cache-only store for one of them is a compile error naming the feature.

Markdown for agents: /docs/caches-drivers-and-what-they-hold.md.Built from Jadpo main at a707efb.