Skip to main content
Qovery creates it as a Helm release on the environment’s own cluster, as a Blueprint service in one of your environments.
New to this? You don’t need to know Kubernetes or Helm. Qovery installs Redis on your cluster with Helm and runs it for you: you fill in a form, or paste the prompt below into your coding agent. The values it publishes, listed under Outputs, reach your other services as environment variables. Qovery tells you when a newer version of the Blueprint is available. Check the requirements in the Reference section before you start, and try it first in a development environment.

Create it

  1. Open the environment, then New service › Blueprint.
  2. Find Redis in the catalog and pick the major version.
  3. Fill in the variables. Required ones are marked; the others use their defaults.
  4. Create the service, and deploy it now or later.
You don’t add any file to your repository. Qovery creates the Blueprint from the Console or the API.

Variables and outputs

Generated from qbm.yml at HELM/redis/8/1.0.3, the manifest the Console form is built from.
Outputs become environment variables that other services in the environment can use. By default Qovery also creates an alias for each output, prefixed with the Blueprint’s name; see Aliases Qovery creates for outputs for the naming rules and the cases where no alias is created.

Reference

From the Blueprint’s README. Deploys Redis cache via the community groundhog2k Helm chart, which wraps the official docker.io/redis image (Redis 8). Standalone, single instance. Data is not persisted — pod restarts clear all keys.
Security note: the official Redis image has no password env var, so requirepass is set via redis.conf, which the chart renders into a ConfigMap in plaintext (not a Secret). Fine for a non-persistent dev cache; do not store sensitive data.

Variables

Outputs