Redis alternatives for ContextForge?

[EricWilson-BluePrism]

Are there alternative caching platforms that can be used with ContextForge, or is Redis the only supported platform right now? I think the answer is the latter but just wanted to make sure.

[crivetimihai]

Hi @EricWilson-BluePrism, thanks for asking.

Redis is entirely optional for development, but it provides a massive performance boost and is required for supported production deployments. We have a pluggable cache backend system (ADR-007) with four options, controlled by the CACHE_TYPE environment variable:

Backend	CACHE_TYPE	Use Case
Database	database	Default. Uses SQLAlchemy (SQLite or PostgreSQL). Works for dev/testing without Redis.
Memory	memory	In-process only. Good for single-worker dev/testing. State lost on restart.
Redis	redis	Distributed caching, pub/sub invalidation, horizontal scaling. Required for production.
None	none	Dummy/no-op cache. For testing or when you want to disable session tracking entirely.

Out of the box the default is CACHE_TYPE=database, so no Redis needed for getting started. Internally we use a two-tier caching pattern (L1 in-memory + L2 Redis) — auth caching alone cuts 70-80% of DB overhead per request, and tool lookup caching reduces DB traffic by 80-95% on hot paths. For production workloads, Redis is what makes the gateway performant at scale.

Regarding Redis-compatible alternatives (Valkey, KeyDB, DragonflyDB): we haven't explicitly tested these, but since we use the standard redis-py client with a standard redis:// connection URL, any drop-in Redis-protocol-compatible system should work. If you try one, I'd love to hear how it goes.

Config in .env:

CACHE_TYPE=database   # or memory, redis, none
REDIS_URL=redis://localhost:6379/0  # only used when CACHE_TYPE=redis

[EricWilson-BluePrism]

@crivetimihai thank you for the info.

Cheers,
Eric