# Memorystore Redis > ZopDay creates a Memorystore for Redis instance on your VPC through private services access, with AUTH and in-transit encryption on and a firewall rule for its traffic. The Memory / Nodes value on the Provision screen, 1 by default, sets both the memory in GB and the tier: 1 gives BASIC, 2 or more gives STANDARD_HA. Source: https://zop.dev/integrations/provision/gcp/memorystore-redis Updated: 2026-08-19 --- Memorystore is Google's managed Redis service. ZopDay creates the instance on your VPC through private services access and stores its connection details in Secret Manager. ## What does a Memorystore job create The examples below use a job called `shop`. - A new network when you choose **Create new VPC**: `shop-network`, with a private subnet, a firewall rule for internal traffic, a Cloud Router and Cloud NAT. - Private services access on the VPC, if it is not there yet. This is a reserved /16 range named after the network (`google-managed-services-shop-network`) plus a service networking connection. Cloud SQL instances on the same VPC share it. - A firewall rule, `shop-datastore-allow`, allowing TCP 3306, 5432 and 6379 from `10.0.0.0/8`. That is the whole 10.x private block, wider than the default 10.0.0.0/16 VPC range. - The Memorystore instance, authorised on the VPC. Its connect mode is `PRIVATE_SERVICE_ACCESS`, AUTH is on and transit encryption is `SERVER_AUTHENTICATION`. - A Secret Manager secret, `zop-ds-shop`, holding the endpoint (the instance's private host), port 6379, a username and a password. ## Which Provision screen fields does Memorystore actually use ```text Memory / Nodes 1 by default (1 to 6); sets the memory size in GB, and 2 or more selects STANDARD_HA Node type BASIC or STANDARD_HA Engine Version REDIS_7_2, REDIS_7_0 or REDIS_6_X Public Access off by default ``` On GCP, the instance follows only the Memory / Nodes value. ZopDay does not pass the node type, engine version or public access fields to Memorystore today. As a result: - the tier comes from Memory / Nodes; - the Redis version is Google's default for new instances; - the instance has only a private endpoint. A STANDARD_HA instance has a replica and automatic failover. To get one, set Memory / Nodes to 2 or more, which also makes the instance at least 2 GB. High Availability, Deletion Protection and Automated Backups are not offered for Redis. ## Why the stored password is not the Memorystore AUTH string The password stored in `zop-ds-shop` is a 32-character value that ZopDay generates. It is not the instance's AUTH string. Memorystore generates the AUTH string itself when AUTH is on, so read it from Memorystore when you set up clients. When you connect the instance to a cluster, ZopDay writes `REDIS_HOST`, `REDIS_PORT`, `REDIS_PASSWORD` and `REDIS_URL` into a Kubernetes secret in `zop-system`. These come from the same stored values. Clients must use TLS because transit encryption is on. ## How do applications reach a Memorystore instance There is no in-cluster alias. Applications reach the instance's private host over the VPC. A cluster on a different VPC needs a VPC peering, which ZopDay creates when you connect the instance to that cluster. Both networks must be in the same project, and their address ranges must not overlap. That rules out two networks created from the Provision screen, since both use 10.0.0.0/16. Replacing the instance changes its address, so read it from the secret instead of hard-coding it. ## What does deleting a Memorystore job remove Deleting the job removes, in order: - the secret; - the instance; - every firewall rule on the network whose name ends in `-datastore-allow`, including rules that belong to other databases or caches; - the network, if ZopDay created it for this job, including the private services access peering and range. ## Which Redis features Memorystore jobs leave unset ZopDay does not set persistence (RDB or AOF), maintenance windows, read replicas beyond the STANDARD_HA replica, or Redis Cluster mode. It never changes the instance's size on its own after creation.