Connecting to Valkey

Any Redis-compatible client library connects to Valkey unchanged — the wire protocol, commands and authentication are the same. What varies by tier is how the driver should be configured.

The in-project endpoint

Containers in the same project reach the instance at its handle on port 6379:

<valkey-handle>:6379

Pass it to your application as an environment variable:

VALKEY_URL=redis://:<password>@session-cache:6379

Access is restricted to the project by network isolation; an instance is never reachable from other projects. To reach an instance from outside the platform, see External access.

Credentials

Authentication is on by default. The platform generates a password at creation — it is never returned by the API, and can be revealed once from the instance's detail page in the console. Revealing a credential is recorded in the activity log.

Clients authenticate the standard way (AUTH, or the password component of a redis:// URL). If you turn authentication off on an instance that is not externally exposed, connections inside the project need no password.

Per-tier driver configuration

Single — connect straight to <handle>:6379. Any client works.

Highly Available (Sentinel) — configure your client in Sentinel mode so it follows automatic failover. The Sentinel endpoint is the instance handle with a -sentinel suffix on the standard Sentinel port:

sentinel address:  <valkey-handle>-sentinel:26379
master name:       <valkey-handle>

A client pointed only at <handle>:6379 will work until the first failover, then reconnect to whatever node holds that address — Sentinel mode is what makes failover invisible to your application.

Sharded (Cluster) — configure your client in cluster mode with <handle>:6379 as the seed address. The driver discovers the shard layout from the cluster itself and follows redirects as the keyspace moves. Remember the hash-tag rule for multi-key operations.

Read scaling

HA and sharded instances also expose a read-only endpoint at <valkey-handle>-readonly:6379, which spreads reads across replicas. Use it for read-heavy paths that tolerate replication lag; writes always go through the primary endpoint.

Multi-region applications

Each region runs an independent copy of the instance, and the in-project endpoint always resolves to the copy in the container's own region. A container in Helsinki talks to the Helsinki instance; the same container image running in Singapore talks to the Singapore instance. No configuration changes per region — the same handle works everywhere.