Valkey parameters
Tune valkey.conf parameters on a Valkey cluster — defaults, persistence and durability, value formats, which changes trigger a rolling restart, and the names the platform manages.
A Valkey cluster's Parameters tab lets you set valkey.conf parameters.
Parameters can also be set at creation in the Advanced flow.
Parameters
The tab lists the parameters available for the cluster's Valkey version (8.1, 9.0, or 9.1), with each default shown under the parameter's name. Setting a value overrides the default; clearing the input removes the override and reverts to the default. A name that is not a parameter of the cluster's version is rejected.
Defaults
When you don't set them, the platform uses:
| Parameter | Default |
|---|---|
maxmemory-policy | noeviction |
save | "" — no periodic snapshots |
shutdown-on-sigterm | save; save failover on cluster-mode clusters running Valkey 9.0 or later, so a stopping primary hands its slots to a replica |
client-output-buffer-limit | replica class only: a hard limit of 5% of the node's memory (at least 32 MiB) and a soft limit of half that for 60 seconds, so a replica that cannot keep up is disconnected instead of exhausting the primary's memory |
appendfsync and auto-aof-rewrite-percentage have no effect while the
append-only file is off.
Persistence and durability
Persistence is RDB only. The append-only file is off, and appendonly
cannot be set until point-in-time restore is available. A node writes a snapshot
when it shuts down (restart, rolling restart, pause) and before each backup, and
a replica writes the snapshot it receives during a full sync. Snapshots are
never periodic unless you set save.
A crash or out-of-memory kill of the primary can lose the writes since its
last snapshot, in replicated clusters too: replication is asynchronous, and a
primary that restarts before failing over comes back with its last snapshot,
which its replicas then resync from. A crashed replica resyncs from the
primary. If that loss matters, set save (for example 3600 1 300 100 60 10000) to
take periodic snapshots.
Disk
A save writes the new snapshot next to the current one before replacing it, so
a node needs about 2× maxmemory of disk at peak. Storage is provisioned
automatically to at least 1.5× the node's memory (3× maxmemory), rounded
up to a whole GiB. When storage autoscaling is on, its maximum is raised along
with it.
Values
| Type | Accepted values |
|---|---|
| Boolean | yes or no |
| Integer | A whole number within the parameter's range |
| Memory | An integer with an optional unit, for example 64mb or 1gb |
| Enum | One of the listed values |
| Multi-value enum | One or more of the listed values, separated by spaces |
| String | Free text, for example TLSv1.2 TLSv1.3 for tls-protocols |
Memory units are case-insensitive:
| Unit | Bytes |
|---|---|
b (or none) | 1 |
k | 1,000 |
kb | 1,024 |
m | 1,000,000 |
mb | 1,048,576 |
g | 1,000,000,000 |
gb | 1,073,741,824 |
maxmemory-clients also accepts a percentage of maxmemory, from 0% to
100%.
Multi-value enums such as shutdown-on-sigterm and shutdown-on-sigint take a
set of flags, for example save now.
Values must not contain control characters such as line breaks or tabs.
Names and aliases
Names are case-insensitive. A parameter set under one of its aliases is stored
under its canonical name: slowlog-max-len is stored as
commandlog-slow-execution-max-len, and slave-priority as replica-priority.
Setting the same parameter under two names is rejected.
How changes are applied
Some parameters require a restart to take effect. These are marked with a
restart chip.
- Hot parameters are applied live to every node. Nothing restarts.
- Restart parameters, and removing any parameter, are applied through a rolling restart: replicas restart first, one at a time, then the primary fails over to a replica and restarts. A node without replicas restarts in place, with downtime.
When the cluster has a maintenance window, a rolling restart waits for it. Hot parameters always apply at once.
Platform-managed parameters
These parameters are managed by the platform and cannot be set, under their own names or any alias:
- Networking —
bind,port,protected-mode,unixsocket,unixsocketperm - TLS —
tls-port,tls-cert-file,tls-key-file,tls-ca-cert-file,tls-ca-cert-dir,tls-client-cert-file,tls-client-key-file,tls-auth-clients,tls-replication,tls-cluster - Persistence layout —
dir,dbfilename,appendonly,appenddirname,appendfilename - Authentication —
aclfile,user,requirepass,primaryuser(masteruser),primaryauth(masterauth) - Topology —
replicaof(slaveof),replica-announce-ip(slave-announce-ip),replica-announce-port(slave-announce-port),cluster-enabled,cluster-config-file,cluster-port,cluster-preferred-endpoint-type,cluster-announce-ip,cluster-announce-hostname,cluster-announce-port,cluster-announce-tls-port,cluster-announce-bus-port - Memory —
maxmemory, set to 50% of the node's memory; the rest is headroom for the fork that syncs a replica and for replica output buffers - Logging and process control —
log-format,log-timestamp-format,logfile,daemonize,supervised,pidfile,include - Modules and safety —
loadmodule,rename-command,enable-debug-command,enable-module-command,enable-protected-configs
Other tls-* and cluster-* parameters can be set, for example
tls-protocols, tls-ciphersuites, and cluster-node-timeout.