Sessions, queues, counters, pub/sub and caching on the datastore your Redis clients already speak — from a single node to a sharded cluster, managed through the same console, CLI and Terraform provider as the rest of your platform.
Valkey is the Linux Foundation's community fork of Redis 7.2, created when Redis moved away from its open-source licence, and backed by the industry's largest cloud providers. It stays under the permissive BSD 3-Clause licence — the commands, data structures and wire protocol your applications already use, with open governance and no licensing uncertainty underneath them.
Existing Redis client libraries connect unchanged — same protocol, same commands, same semantics, including Sentinel discovery and cluster redirects. Point your connection string at the instance handle on port 6379 and keep the code you have. Migrating off a hosted Redis is a connection-string change, not a rewrite.
Create an instance as a cache (in-memory only, least-recently-used eviction) or a store(disk persistence, storage sizing, eviction off by default, free scheduled backups). The purpose sets honest defaults for what happens when memory fills and what survives a restart — so a full cache drops cold entries while a full store refuses to lose data.
A single node for rebuildable data. A highly available tier with automatic failover in seconds. A sharded cluster that grows capacity with your keyspace. Standard and hardened sizes trade nodes for tighter failure tolerance — and the console shows the derived node count and a live cost estimate before you create anything.
Platform features
Everything an in-memory datastore needs in production — provisioning, security, backups and visibility — without operating any of it.
Topologies
One node, a Sentinel-coordinated highly available tier (3 or 5 nodes), or a sharded cluster (from 6 nodes, growing with shards). The tier decides failover behaviour and which client driver your application needs — and nothing else about your code.
Durability
Store instances persist to disk and recover their data across restarts. Scheduled backups are free — a cron schedule you control, with the last seven days of snapshots retained as your recovery path.
Security
Instances are project-private by default. External exposure requires TLS, authentication and an IP allowlist — all three, enforced by the platform. There is no way to put an open datastore on the internet.
TLS
With managed TLS, the platform issues a certificate covering every name the instance answers to — per-region hostnames, per-node names, and your custom domains — and keeps it current as the instance changes. Or bring your own bundle from the vault.
Multi-region
Each region runs an independent copy with its own data — the right shape for active-active deployments. Your containers always talk to the copy in their own region using the same handle, with no per-region configuration.
Automation
Create and manage instances from the console with a live cost estimate, from the Reis CLI in flag or YAML mode, or declaratively through the Terraform provider — the same resource model as every other Bahriya resource.
Scaling reads
Highly available and sharded instances expose a second endpoint that spreads reads across replicas. Send read-heavy paths that tolerate replication lag there, and keep writes on the primary endpoint.
Memory
The default follows the purpose — a cache evicts the least recently used keys, a store refuses writes rather than lose data. Switch to any of the eight eviction policies, LRU or LFU, all keys or only those with an expiry, whenever your access pattern calls for it.
Credentials
Authentication is on by default with a platform-generated password, kept in your vault as a managed secret attached to the project — so a container can reference it like any other secret. Reveal it from the console; every reveal is in the activity log.
Networking
Attach network policies to an instance to decide exactly which projects and destinations it can talk to, alongside the rest of your project networking. Private by default stays the starting point.
Observability
Follow each instance from the console: runtime metrics, server logs and deployment events per region, the snapshots on its Backups tab, and its billing — without running a monitoring stack of your own.
Tuning
Beyond memory and eviction, tune tcp-keepalive, timeout, tcp-backlog, databases and loglevel per instance. Everything else stays managed by the platform.
Persistence and backups
Store instances keep their data on disk and back it up on your schedule, at no extra charge.
A store writes both a periodic snapshot and an append-only log of writes to its own volume. After a restart a node replays them and comes back with its data — which is what makes a single-node store viable, and what replicas recover from on the HA and sharded tiers.
Turn backups on with a toggle and set a cron schedule — daily at 02:00 by default. The last seven days of snapshots are kept, each region backed up independently, and every snapshot is listed with its time, region and size.
Pick a snapshot on the instance's Backups tab and restore it into the region it came from. The console asks you to confirm, because a restore replaces that region's current data — the other regions are left untouched.
Storage is set per node in GB and billed per region. Size it comfortably above your memory setting so the snapshot and the append-only log have room to grow between compactions.
Operating it
Memory, regions, eviction and exposure are configuration. The platform applies the change; you keep shipping.
Memory is set per node, from 256 MB to 16 GB. Sharded instances start at three shards and grow in self-service as your keyspace does — capacity and write throughput rise with every shard, and failover happens independently per shard.
Memory, regions, eviction policy and exposure changes apply as a rolling update in every selected region, so a highly available instance keeps serving while it changes.
Single nodes take any client. Highly available instances want a Sentinel-aware driver so failover is invisible to your application; sharded instances want a cluster-aware driver and hash tags for keys you operate on together. It is connection configuration, not a rewrite.
Roles decide who can create, change or reveal the password for an instance, and an instance can be shared with a single person without opening up the whole project. Every change, reveal, restore and certificate renewal is recorded in the activity log.
Use cases
Valkey's data structures carry real application state — pick the purpose and tier that match what the data means to you.
Session stores, query caches and computed results on a cache instance — least-recently-used eviction keeps the hot set in memory, and eight eviction policies let you tune exactly what gives way when memory fills.
Lists and streams back job queues that must survive a restart — a store instance persists to disk, refuses to evict, and backs itself up on your schedule. Pair it with worker containers in the same project.
Atomic increments, sorted sets and expiring keys make Valkey the natural home for rate limiting, usage counters and ranking — with the highly available tier keeping them online through node failures.
Publish/subscribe channels and streams power presence, notifications and live updates between your services — project-private by default, or exposed externally over TLS to services hosted elsewhere.
Purpose, tier, memory and regions with sensible defaults, a derived node count, and a live cost estimate before you create.
Memory is billed per node, storage per region — the estimate on the form is the same arithmetic as the invoice.
Status, node counts, connection endpoints and credential reveals in the console, with every change in the activity log.
Topologies, eviction, persistence, backups and external access — covered in the knowledgebase with CLI and Terraform examples.
Available and planned
Services marked Available can be deployed today. The others are planned, and their timing may change.
Managed PostgreSQL with automated backups, point-in-time recovery, and regional deployment. Advanced SQL features, JSONB support, and extensions for modern application workloads.
A globally distributed, multi-region document database with built-in replication. Conflict-free sync across regions for offline-first applications and geo-distributed NoSQL workloads.
S3-compatible object storage for files, media, backups, and static assets. Accessible from your containers or directly via standard S3 APIs and client libraries.
Global content delivery network for static assets, media, and API acceleration. Edge caching across multiple PoPs with automatic origin pull from your containers or object storage.
Your own dedicated API gateway in front of your services. JWT/OAuth2/OIDC and key auth, fine-grained rate limiting and quotas, request/response transformations, circuit breakers, canary releases and traffic splitting, gRPC and WebSocket proxying, and rich per-route analytics — all configured declaratively via Reis or the Console.
Managed RabbitMQ for asynchronous messaging between containers. Multi-region clusters, project-private networking, and per-node billing — same operational model as Memcached.
Create an instance next to your containers, point your existing Redis client at it, and keep your data on an open-source datastore.
