Valkey

Bahriya provides managed Valkey instances — an in-memory datastore for caching, sessions, queues, counters, pub/sub and real-time data, deployed alongside your containers and managed from the same console, CLI and Terraform provider as everything else.

What Valkey is

Valkey is an open-source, high-performance key-value datastore stewarded by the Linux Foundation. It began in 2024 as a community fork of Redis 7.2, created when Redis moved away from its open-source licence, and is backed by major cloud and technology companies. Valkey remains under the permissive BSD 3-Clause licence.

For your application, Valkey is a drop-in replacement for Redis:

• It speaks the same wire protocol, so existing Redis client libraries work unchanged.
• The command set, data structures (strings, hashes, lists, sets, sorted sets, streams) and semantics you know from Redis 7 are all there.
• Connection strings, Sentinel discovery and cluster redirects behave the way Redis-aware drivers expect.

You keep your code and your libraries, and gain a datastore with an open governance model and no licensing uncertainty.

Cache or store — pick a purpose

Every instance has a purpose, chosen at creation and immutable afterwards. The purpose is a bundle of defaults, not a hard limit:

The purpose is immutable because turning persistence on for a live instance is a migration, not a setting. If a cache grows into a system of record, create a store instance and move the data.

Creating an instance

Create instances from the console, the Reis CLI or Terraform. Each instance needs:

• Name and handle — a display name and a permanent identifier.
• Project — the project it belongs to; containers in the same project reach it over the internal network.
• Purpose — cache or store, as above.
• Tier — single, ha or sharded; see Topologies.
• Memory — per node, from 256 MB to 16 GB.
• Regions — one or more. Each region runs an independent copy with its own data; there is no cross-region replication.

The console shows a live pricing estimate as you adjust tier, memory, storage and regions. Memory is billed per node, storage per region — the derived node count shown on the form is the multiplier.

Connecting

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

<valkey-handle>:6379

Authentication is on by default with a platform-generated password you reveal once from the console. See Connecting to Valkey for driver guidance per tier, and External access for reaching an instance from outside the platform.

Configuration tuning

Beyond the sizing controls, a small set of server settings can be tuned per instance: tcp-keepalive, timeout, tcp-backlog, databases and loglevel. Anything else stays managed by the platform.

Lifecycle

Instances move through provisioning → running, and terminating → terminated when deleted. Updates — memory, regions, eviction policy, exposure settings — apply as a rolling update in every selected region. Deleting an instance deletes its data; for store instances, backups are the recovery path.

Availability

Valkey is rolling out progressively. If it is not yet visible for your organisation, contact support to request access.

In this section

• Topologies — single, highly available and sharded tiers, and how to choose.
• Connecting to Valkey — endpoints, credentials and client drivers.
• Eviction policies — what each policy does and when to use it.
• External access — TLS, hostnames and IP allowlists at the platform edge.
• Persistence and backups — durability for store instances.