Connect to a store

The connection details carry the store's password, so showing them needs valkey/readSecrets — even for a store without a password. The Owner, Contributor and Databases Operator roles have it. Every time they are shown is recorded in the store's activity log.

Get the connection details

On the store's Overview, under Connection, choose Show connection info. It shows:

• Host — <store>.<namespace>.svc.cluster.local:6379, the store's in-cluster name and port; <namespace> is the resource group's namespace on the cluster. A workload in the same resource group can also use the store's name alone.

• URI — the same with the password, ready for a client that takes a URI:

  textCopy code

  valkey://:<password>@<store>.<namespace>.svc.cluster.local:6379

  The password stands where a user name and password would, with an empty user name, and is URL-encoded. A store without a password has valkey://<store>.<namespace>.svc.cluster.local:6379.

There is no CLI command for the connection details; call the API route instead, which returns the host, port and password separately as well as the URI:

stsh api GET /boundaries/<boundary-id>/resourcegroups/<resource-group>/resources/valkeys/my-cache/connectioninfo

Use it in a workload

The platform does not hand the connection details to your workloads by itself. Keep the URI, or the password, in a vault and reference it from the workload:

1. Add it as a secret in a vault — see Add a secret.
2. Reference the secret from the workload: for an app or a function see Add a secret reference, for a container instance see Container instances.

Only workloads in the store's boundary can reach it. Write the client to expect an empty cache and a dropped connection after the store restarts — see A cache, not a database.

Connect from outside the cluster

1. On the store's Configuration tab, open Networking & Security, turn on External access and save. The platform provisions a load balancer on port 6379.
2. Enter Allowed CIDR ranges, separated by commas — 10.0.0.0/16, 192.168.1.0/24 — to let only those networks in. They apply to external access only; inside the cluster the boundary's network rules decide.

Warning

Three things to know before you turn it on:

• The portal and the API do not show the load balancer's address today: the connection details always name the in-cluster host.
• Traffic is not encrypted. The password and every key and value cross the network in plain text.
• Turning External access off again does not remove the load balancer; the store stays reachable from outside.

Rotate the password

The portal has no action for it; the API does. Rotating needs valkey/writeSecrets, which the Owner, Contributor and Databases Operator roles have:

stsh api POST /boundaries/<boundary-id>/resourcegroups/<resource-group>/resources/valkeys/my-cache/password/rotate

The answer holds the new password, 32 letters and digits. The server reads its password only when it starts, and the restart the rotation asks for is not carried out by itself — see Stop, start and restart.

Caution

Until the server restarts, the old password keeps working and the new one is refused. Stop and start the store right after rotating; this empties the cache.

Then update the secret in the vault, and restart the workloads that read it — see When a value changes. A store with Require a password off has no password to rotate, and the platform refuses.