Deploy and control
Deploy CacheDB
Choose a CacheDB deployment model with protected configuration, explicit ownership, and durable operational state.
CacheDB supports two operating models: Linux hosts managed through systemd
and cdb-install, or ordinary OCI containers. Both use locally available
packages, images, and configuration. The installer is offline-capable: it does
not download drivers, licences, or vendor configuration.
Choose the operating model
| Model | Use it when | What the operator owns |
|---|---|---|
| Linux and systemd | You want service accounts, host lifecycle controls, and explicit installation planning. | Packages, protected TOML, service ownership, backups, and network placement. |
| OCI containers | You operate container workloads and want one process per container. | Read-only configuration mounts, durable console storage, driver mounts, and orchestration. |
Containers do not remove the operational responsibilities. In particular, the console SQLite database must use persistent storage or accounts, roles, audit history, and alerts will not survive a container replacement.
Plan before changing a host
On a systemd host, cdb-install separates read-only planning and diagnostics
from apply. Its answer file contains identifiers and configuration paths, not
passwords, OIDC secrets, or licence material.
cdb-install plan --answers /root/cachedb-orders-install.toml
cdb-install doctor --answers /root/cachedb-orders-install.toml
cdb-install doctor --answers /root/cachedb-orders-install.toml --check-connectivityplan and doctor validate the local deployment without contacting external
systems. Connectivity checks are explicit. After review, root applies only
managed service units; CacheDB does not infer customer data paths or purge
configuration, Redis, logs, or backups.
Protect configuration and identity
Proxy and console TOML files can contain database, Redis, OIDC, and other
credentials. Use an absolute path, ownership by the service account, and mode
0600. Keep a cache namespace tied to one database service identity; do not
share it across applications with different data permissions or row-level
visibility.
CacheDB needs Redis for cache operations and can use a separate Redis target for metrics. Each target can use Sentinel for failover; Redis Cluster is not a supported cache topology in this release.
Place the components deliberately
CacheDB’s proxy and Redis paths have documented transport limits. Keep proxy, database, and Redis on a trusted private segment, or provide encryption at the network layer. Put a console reachable beyond loopback behind an edge that provides TLS, rate limiting, and access control.
These are deployment decisions, not optional hardening later. See Compatibility & security for the precise 1.9 boundaries.
Deployment checklist
- Choose the application protocol and proxy path.
- Supply locally available packages or OCI images and any required vendor drivers.
- Protect configuration and assign the service identity.
- Define cache and metrics Redis topology, persistence, and backup ownership.
- Start the representative workload in transparent mode.
- Place proxy dependencies and console access within the documented network boundary.
For a topology or operating-model review, discuss a CacheDB deployment design.