Deploy CacheDB

CacheDB can run as Linux services or in OCI containers. In either model, plan for the proxy processes, database paths, cache infrastructure, console storage, and access boundaries as one system.

Plan the topology

Place each proxy on the application request path and configure its database target and cache dependencies. Redis Community, Valkey, and Redis Enterprise can provide the shared cache used by multiple proxies. Keep cache connections on a trusted network; CacheDB does not provide TLS on these connections, so use network-level protection where required. Use persistent storage for console state, including tenant configuration, accounts, audit history, and alerts.

For proxy high availability, place multiple shared-nothing instances behind a load balancer that sends connections only to healthy proxies. Keep their policy and target configuration aligned. Assess cache and backend availability separately against the application’s requirements.

Protect configuration and traffic

Treat database, cache, identity-provider, and licensing values as secrets. Restrict configuration files to the service identity and keep backups and restore procedures for durable state. Native database proxies support TLS 1.2 or later on client and backend legs. Backend certificates are verified by default; configure plaintext explicitly only where appropriate.

The console is served behind a TLS-terminating reverse proxy or WAF. Apply network access rules and request limits at that edge, and expose only the console routes intended for each tenant.

Roll out in stages

1. Verify the database protocol, driver, and database version.
2. Deploy to a representative environment with transparent mode enabled.
3. Confirm connection behavior, observability, and operational access.
4. Review cache eligibility, freshness, and invalidation rules.
5. Enable cache reuse for the intended workload and monitor its outcome.