Enabling Redis & tooling

The memory backend is the always-on default — there is nothing to install to start caching. Switching to Redis is two concerns: flip the backend (app.config / env) and provision the infra to run it (a container in compose, a Deployment in helm, the env vars). The CLI does both for you.

#At project creation

voltro create-project myApp --baseline=compose --cache=redis

--cache=redis sets cache: 'redis' in the api app.config.ts and, because a baseline was chosen, injects a redis service into the compose docker-compose.yml (or a Deployment + Service + values into the helm chart) plus CACHE_BACKEND / CACHE_REDIS_URL into .env.example.

#Later, on an existing project

voltro add redis

The same idempotent wiring, applied to the project at the cwd:

1. flips every api app.config.ts to cache: 'redis'
2. injects a redis service into docker-compose.yml (if the compose baseline is present)
3. injects a redis values block + a Deployment/Service into the helm chart (if the helm baseline is present)
4. activates CACHE_BACKEND / CACHE_REDIS_URL in .env.example — uncommenting the baseline's optional-backends block in place, or appending it if absent (and .env if it exists)

Every baseline ships that block commented-out in .env.example from the start — the cache and the durable-KV Redis vars — so a fresh project already shows what it can turn on. voltro add redis just uncomments the cache half; the durable-KV vars stay commented on purpose (durable KV wants a persistent Redis, not the ephemeral cache one this command provisions — see Key-value backends).

It only touches infra files that exist — a bare-baseline project just gets the app.config + .env changes. Re-running is safe (each step checks for an existing marker and skips). Caching is a backend + infrastructure concern, not a runtime plugin, so there is deliberately no plugins: entry and no voltro plugin add for it.

Then start Redis and reboot:

docker compose up -d redis
voltro dev .
# boot log: cache backend resolved: redis (driver resp)

For the engine matrix (Redis / Valkey / KeyDB / Dragonfly / Upstash) and all env vars, see Backends & engines.

#The voltro cache CLI

voltro cache status                 # resolved backend + hit/miss counters
voltro cache flush                  # clear every entry (redis backend)
voltro cache invalidate <tag>       # drop everything carrying <tag>

flush / invalidate operate on the shared store, so against redis they affect every instance. Against the memory backend they're refused (the CLI can't reach another process's in-memory map) — status still reports the config.

#Dashboard

The local DevTools dashboard and the Voltro Cloud dashboard both show a per-app Cache panel — resolved backend/engine, driver, and live hit-rate (hits / misses) — backed by GET /_voltro/inspect/data-cache. Same surface in both, so what you see locally matches production.