Valkey

Redis-compatible in-memory key-value store with high availability, persistence, and TLS.

Versions

Version	Status
8	Available (recommended)

Connecting

Port	Scope	Use
6380	Public (TLS)	Production client traffic, always use this
6379	SDN-internal	Replication between nodes and Sentinel monitoring

6380 is the only port reachable from the public internet, and only from the CIDRs in your allowed_cidrs list. All client traffic on 6380 is TLS, so the connection is encrypted end to end.

6379 is bound to the private SDN that the cluster nodes share. It carries the replication stream from the primary to its replicas and the Sentinel monitoring traffic. It is blocked at the cloud-edge firewall and is not used by application clients.

# TLS
redis-cli -h HOST -p 6380 --tls --user USER --pass PASS

# Test
redis-cli -h HOST -p 6380 --tls --user USER --pass PASS PING

Full connection string examples: Connection Strings →

High Availability (Sentinel)

For HA, add a replica. The primary accepts reads and writes and streams its dataset to each replica using asynchronous replication over the SDN-internal port 6379. Replicas are read-only and apply the stream as it arrives, so they trail the primary by a small, usually sub-second, amount. Read traffic can be served from a replica; all writes go to the primary.

A set of Sentinel processes continuously monitors the primary on 6379. When enough Sentinels independently agree the primary is unreachable (quorum), they elect one of them to coordinate a failover, promote a replica to primary, point the remaining replicas at the new primary, and move client traffic to it. Requiring a quorum (rather than a single observer) prevents a single Sentinel with a bad network path from triggering a spurious failover.

Valkey replication & Sentinel failover

FAILOVER Replica promoted · clients redirected :6380

ClientsTLS :6380redirected →Primary (new)promoted⇢ repl :6379Replica 2read-only

Primary (rw)Replica (read-only)Promoted primarySentinelRDB / AOFClient TLS :6380 (public)SDN-internal :6379 (dashed)

The diagram above shows the steady state (async replication on 6379, RDB and AOF persistence on the primary, Sentinels monitoring) and the failover beat: the primary goes unreachable, the Sentinels reach quorum, a replica is promoted, the surviving replica re-follows it, and clients are redirected to the new primary on 6380.

Add a replica:

curl -u admin:password -X POST \
  https://api.foundrydb.com/managed-services/{id}/nodes \
  -H "Content-Type: application/json" \
  -d '{"role": "replica"}'

Failover time is typically 5–15 seconds. Because replication is asynchronous, writes that the old primary had not yet shipped to the promoted replica can be lost on failover. Configure your client with retry logic and connection timeouts so it reconnects to the new primary after a promotion.

Manual failover:

curl -u admin:password -X POST \
  https://api.foundrydb.com/managed-services/{id}/nodes/{node_id}/failover

Persistence

Valkey holds the dataset in memory. To survive restarts it writes to disk using two complementary mechanisms, both enabled by default:

Mode	Behaviour
RDB	Point-in-time snapshots. Fast restarts, small files. Risk of up to ~minutes of data loss.
AOF	Log of every write. Near-zero data loss, larger files, slower restarts.

Running both gives you the AOF's durability for recovery plus the RDB snapshot for compact backups and faster reloads. The save parameter controls when a new RDB snapshot is taken (after N keys change within M seconds), and appendfsync controls how often the AOF is flushed to disk. The AOF is periodically rewritten into a compact form so it does not grow without bound. On restart, the node reloads its dataset from disk before accepting traffic.

Persistence is local to each node and is independent of replication: a replica keeps its own RDB and AOF, so a node that restarts can warm itself from disk rather than re-syncing the whole dataset from the primary.

Tune persistence:

curl -u admin:password -X PATCH \
  https://api.foundrydb.com/managed-services/{id}/configuration \
  -H "Content-Type: application/json" \
  -d '{
    "parameters": {
      "appendonly": "yes",
      "appendfsync": "everysec",
      "save": "3600 1 300 100 60 10000"
    }
  }'

appendfsync values:

• always, safest, slowest
• everysec, recommended balance
• no, fastest, OS-controlled flush

Eviction Policies

Set how keys are evicted when memory is full:

"parameters": {
  "maxmemory-policy": "allkeys-lru"
}

Policy	Description
noeviction	Return errors when full (default)
allkeys-lru	Evict least recently used keys
volatile-lru	Evict LRU keys with TTL set
allkeys-random	Evict random keys
volatile-ttl	Evict keys with shortest TTL

Configuration

curl -u admin:password -X PATCH \
  https://api.foundrydb.com/managed-services/{id}/configuration \
  -H "Content-Type: application/json" \
  -d '{
    "parameters": {
      "maxmemory-policy": "allkeys-lru",
      "hz": "15",
      "tcp-keepalive": "300",
      "timeout": "0"
    }
  }'

Common parameters:

Parameter	Default	Description
maxmemory-policy	noeviction	Key eviction policy
hz	10	Background task frequency
tcp-keepalive	300	Keepalive probe interval (seconds)
timeout	0	Idle connection timeout (0 = disabled)
lazyfree-lazy-eviction	no	Non-blocking key eviction

Backups

# List backups
curl -u admin:password https://api.foundrydb.com/managed-services/{id}/backups

# Manual backup
curl -u admin:password -X POST \
  https://api.foundrydb.com/managed-services/{id}/backups \
  -H "Content-Type: application/json" \
  -d '{"backup_type": "manual"}'

Metrics

Key metrics: used_memory, connected_clients, keyspace_hits, keyspace_misses, expired_keys, evicted_keys.

curl -u admin:password \
  "https://api.foundrydb.com/managed-services/{id}/metrics?metric=memory&period=1h"