Same client. Your choice of vendor.
GAThe backend is chosen per namespace, not per account and never in your application code. Front managed Redis for one namespace, Cloudflare Durable Objects for another, and your own cluster for a third — the SDK and its methods stay identical. No lock-in is designed in.
The four backends
| Backend | What it is | Reach for it when… |
|---|---|---|
upstash | Managed Redis-over-REST, region-anchored. The default, and it ships now. | You want zero-ops managed KV/queues and don’t need per-POP placement. Start here. |
durable | Cloudflare Durable Objects — strong consistency, per-POP. Opt-in. | You want state co-located at the edge with single-writer strong consistency. |
byo | Your own Redis-compatible HTTPS endpoint. Enterprise, no lock-in. | Compliance or residency requires the data live on infrastructure you control. |
auto | Let TillCache place the namespace on a sensible default backend. | You don’t want to decide up front and are happy with a managed choice. |
Strong vs. eventual
Every namespace has a consistency knob, set independently of the backend:
strong— a read reflects the most recent successful write. Pick it for locks, counters that gate behavior, and anything where a stale read is a correctness bug.eventual— reads may briefly trail the latest write in exchange for lower latency and cheaper cross-region reads. Pick it for caches, feature flags, and read-mostly data that tolerates a little lag.
strong namespace, and put warm read-through cache in an eventual one.Namespaces, tokens & scopes
Namespaces, backends, and tokens live in the control plane — the dashboard at /<org>/cache or the tilldev cache CLI. The data plane is just the one endpoint your SDKs call.
# Upstash-backed, strongly consistent (the default backend):
tilldev cache namespaces create sessions --backend upstash --consistency strong
# Durable Objects, per-POP strong consistency, opt-in:
tilldev cache namespaces create counters --backend durable
# Bring your own Redis-compatible HTTPS endpoint:
tilldev cache namespaces create ledger \
--backend byo \
--endpoint https://redis.internal.example.com \
--consistency strong
# Mint a data-plane token for a namespace:
tilldev cache tokens create --namespace sessions --scope read-write # → tc_…Data-plane tokens (prefix tc_) are scoped to a namespace and carry a read-write or read-only scope. Hand a server a read-write token; give anything less trusted a read-only one.
Bring-your-own endpoints
A byo namespace points at a Redis-compatible HTTPS endpoint you run. Your application still speaks to the one TillCache endpoint with a tc_ token — TillCache proxies to your backend — so you keep the unified client, tokens, allow-list, quotas, and TillPulse observability while the bytes live on your infrastructure.
One view, whatever the backend
Whichever backend a namespace uses, hot keys, queue depth and lag, and slow commands surface in TillPulse the same way. Switching a namespace’s backend doesn’t change your code or your dashboards.