Connecting to Valkey

Connecting to managed Valkey on Bahriya with any Redis-compatible client: endpoints, credentials, and driver configuration per tier on port 6379.

Updated 13 Aug 20263 min read

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, or uses the one you set. It is never returned by the API; reveal it from the instance's detail page in the console. Revealing a credential is recorded in the activity log.

The password is kept in your vault as a secret named after the instance (<handle>-auth) and attached to its project. The platform manages it: you can see it in Vault → Secrets, but you change it through the instance, not the vault. It is billed like any other secret.

  • Changing the password: set a new one on the instance (console, Reis or Terraform). The running instance switches to it on the next deploy, and the old password stops working, so update your clients at the same time. Sending the current password again changes nothing.
  • Turning authentication off removes the secret and its charge. Turning authentication back on issues a new password.
  • Using it from a container: because the secret is attached to the project, you can reference it from a container's secrets like any other vault secret.

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.