Skip to main content
Qovery creates it in the GCP project of the environment’s cluster, as a Blueprint service in one of your environments.
New to this? You don’t need to know Kubernetes or Terraform. Qovery sets up Google Cloud Memorystore for Redis in your cloud account and manages 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 Google Cloud Memorystore for 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 GCP/redis/7/1.0.8, 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.
Secret variables and outputs are encrypted and masked in Qovery, but Terraform can also keep their values, and values derived from them, in its state. With the Qovery-managed state backend (the default), Qovery stores the state. If you use your own backend, protect it and keep state files out of version control.

Reference

From the Blueprint’s README. Creates a GCP Memorystore for Redis 7 instance with configurable tier, memory size, auth, TLS, persistence, maintenance window, and optional cross-zone read replicas. There is no user-supplied password: when auth_enabled is true, GCP generates an AUTH string that is published via the redis_auth_string output.

Variables

Required

Engine & sizing

Auth & network

By default the instance attaches to the project’s default VPC network, which is usually not the Qovery cluster’s VPC. Set authorized_network to the cluster’s VPC self-link (and connect_mode/reserved_ip_range as required by that network’s setup) so pods in the cluster can reach the instance without extra peering. Security note — plaintext by default: transit_encryption_mode defaults to DISABLED. Since auth_enabled also defaults to true, the generated AUTH string and all cache traffic (including the data itself) travel unencrypted over the VPC on every connection — anyone able to observe traffic on that network path can capture both. Memorystore instances are never reachable from the public internet, but this offers no protection against other workloads sharing the same VPC. Set transit_encryption_mode = SERVER_AUTHENTICATION for anything beyond a trusted, fully isolated environment; clients then need to trust the CA certificate published via redis_server_ca_certs and connect over TLS (e.g. rediss://), which most Redis client libraries support but require explicit configuration for.

Persistence

Maintenance

Read replicas

Replicas are asynchronous, cross-zone, read-only copies of the primary; point analytics/BI tools at the redis_read_endpoint output to keep read traffic off the primary. Setting replica_count > 0 requires tier = STANDARD_HA. STANDARD_HA always allocates a standby node for automatic failover, independent of replica_count — GCP requires at least one such node once STANDARD_HA is selected. replica_count = 0 (the default) just means that standby isn’t exposed as a readable replica; the blueprint sends GCP the required minimum under the hood. Set replica_count to 1-5 to also expose it (or additional nodes) via redis_read_endpoint.

Misc

Outputs

Required GCP IAM permissions

The credentials used to deploy this blueprint must be able to manage Memorystore Redis instances in the target project:
roles/redis.admin (or the underlying redis.instances.* permissions) is sufficient for create, read, update, and delete. If authorized_network points at a network in a different (Shared VPC host) project, grant roles/compute.networkUser on that network to the Memorystore Redis service agent of this project — the one hosting the instance (service-PROJECT_NUMBER@cloud-redis.iam.gserviceaccount.com, where PROJECT_NUMBER is gcp_project_id’s project, or the deploy credentials’ default project when gcp_project_id is empty) — not a service agent from the network’s project.