Deploy and control
Console operations
Operate CacheDB through query context, alerts, audit, access controls, and controlled cache-mode changes.
The CacheDB console is the operational surface for understanding traffic, controlling cache behaviour, and retaining evidence of consequential changes. It brings query context, metrics, alerts, access controls, licence state, and audit history together around the proxy fleet.
See the workload before changing it
The dashboard exposes active connections, QPS, backend errors, and—in full mode—cache hits, misses, adds, and invalidations. Operators can select a time range, refresh cadence, and client context. The query view adds normalized fingerprints, statement and table filters, observed execution behavior, cache activity, and invalidation relationships.
Transparent mode keeps this observability available before result reuse is enabled. Cache-specific charts remain hidden when there is no cache activity to report.
Control cache mode deliberately
The console can move a fleet between transparent and full mode without a proxy restart. It publishes the requested state through Redis and each proxy applies it on a subsequent request after checking its own licence state.
Transparent mode is always available. Full caching requires a current active or grace-period licence; an unlicensed instance remains transparent. That makes it possible to contain or assess a workload without accidentally enabling result reuse.
Build for accountable operations
CacheDB retains users, roles, sessions, alerts, audit history, and licence state in its configured SQLite store. Protect and back up that store, including when the console runs in a container. The console can issue durable alerts and send them to configured SMTP or webhook destinations; audit export can support central retention requirements.
Protected mutations and failed authentication or authorization events are recorded with actor, action, target, outcome, and peer context. Optional OIDC supports federated access, with roles used to separate viewing, operations, and administration.
Put the console behind a trusted edge
The console itself listens on HTTP and does not provide TLS termination or built-in login rate limiting. Keep it on loopback or a private network, or put it behind an edge that provides TLS, throttling, and network access control.
For the exact transport and identity boundaries, read Compatibility & security.
Discuss an operations evaluation to review monitoring, audit, alerting, and access expectations.