External access

By default a Valkey instance is reachable only by containers in its own project. You can additionally expose it at the platform edge — for an application hosted elsewhere, a data pipeline, or a migration — on the standard port 6379.

Exposure is TLS-only, authenticated and allowlisted — always

An externally exposed instance must have all three of:

1. TLS on,
2. Authentication on, and
3. a non-empty IP allowlist (CIDR notation, e.g. 198.51.100.0/24, 203.0.113.42/32).

These are enforced by the platform, not defaults you can drift away from — a configuration missing any of them is rejected. There is no way to put an unencrypted, unauthenticated, world-reachable datastore on the internet.

Generated hostnames

Every exposed instance gets a generated hostname per region:

<default-hostname>.<region>.valkey.on.bahriya.app:6379

The console shows the exact endpoint for each selected region on the instance form. Each region is an independent copy with its own data, reachable only at its own name — connecting to the Helsinki endpoint always reaches the Helsinki copy.

Highly available and sharded instances additionally announce per-node names under the same scheme (node-0., node-1., …). You do not connect to these directly — Sentinel discovery and cluster redirects hand them to your driver, which follows them automatically. They matter only in one place: a TLS certificate you supply must cover them.

Custom hostnames

You can attach hostnames of your own — cache.example.com — as convenience names. Point a CNAME at the generated hostname of the region that name should reach:

cache.example.com.  CNAME  my-cache.helsinki-1.valkey.on.bahriya.app.

Every region's edge accepts every custom name, so the CNAME target alone decides which region's copy answers. For a multi-region instance, create one custom name per region (cache-eu.example.com, cache-sg.example.com) and point each at its region's generated hostname.

A custom hostname is a convenience name, not a trust upgrade — your client trusts the instance's certificate authority either way.

TLS certificates: managed or bring your own

Platform managed (recommended). With TLS on and no bundle selected, the platform issues a certificate bundle, stores it in your organisation's vault, and keeps it valid for every name the instance answers to — generated hostnames, per-node names and custom hostnames alike. Add a region or a hostname and the bundle is reissued to cover it. Nothing to renew, nothing to forget.

Bring your own. To serve your own certificate, create a TLS bundle in your vault and attach it to the instance's project — it then becomes selectable on the instance. A supplied bundle must cover every hostname the instance answers to, including the per-node names of HA and sharded tiers; the API rejects a bundle with missing names and tells you which ones. Wildcards are honoured where they match.

Checklist for an external client

1. Address: the generated hostname (or your CNAME) on port 6379.
2. TLS: enabled in your client (rediss:// URLs, or your driver's TLS option).
3. Password: the instance credential, revealed from the console detail page.
4. Source IP: within the instance's allowlist.

rediss://:<password>@my-cache.helsinki-1.valkey.on.bahriya.app:6379

Containers in the same project should keep using the internal endpoint — it is faster and does not depend on the exposure settings.