Valkey CONFIG REWRITE: Persist Runtime Config Changes (2026)

Valkey’s runtime configuration changes are not persistent by default, meaning any CONFIG SET commands you run will vanish when the server restarts.

Let’s see this in action. Imagine you’ve got a Valkey server running, and you want to tweak the maxmemory setting.

# Check current maxmemory
valkey-cli config get maxmemory
# Output: 1073741824 (1GB, for example)

# Change it
valkey-cli config set maxmemory 536870912 # Set to 512MB
# Output: OK

# Verify the change
valkey-cli config get maxmemory
# Output: 536870912

# Now, simulate a restart (e.g., kill the process and start it again)
# ... (assume Valkey restarts) ...

# Check maxmemory again
valkey-cli config get maxmemory
# Output: 1073741824 (It's back to the original value!)

This behavior is by design. Valkey prioritizes speed and simplicity for runtime operations. Applying changes directly to the configuration file on disk could introduce latency or race conditions, especially in high-throughput environments. The CONFIG SET command is meant for immediate, temporary adjustments.

To make these changes permanent, you need to explicitly tell Valkey to rewrite its configuration file. This is done using the CONFIG REWRITE command.

Here’s how you’d make that maxmemory change persistent:

Make the runtime change:

valkey-cli config set maxmemory 536870912

Rewrite the configuration file:
```
valkey-cli config rewrite
```
If successful, this will return OK. Valkey will read its current runtime configuration (including the maxmemory change you just made) and write it to the file specified by the configfile directive in your valkey.conf. If configfile is not set, it will attempt to write to the default valkey.conf in the current directory, which might not be what you want.

Now, if you restart Valkey, the maxmemory setting will remain at 536870912.

The CONFIG REWRITE command is a powerful tool, but it has a few nuances. It doesn’t just append your changes; it essentially reads the entire current runtime configuration and writes a new configuration file based on that. This means any manual edits you made directly to the valkey.conf file that haven’t been applied via CONFIG SET and then CONFIG REWRITE will be lost. It’s crucial to understand that CONFIG REWRITE synchronizes the file with the running server’s state, not the other way around.

Furthermore, CONFIG REWRITE can be a blocking operation, especially on very large configuration files or during periods of high server load, as it needs to acquire a write lock on the configuration file. For this reason, it’s generally recommended to perform configuration rewrites during periods of lower activity.

You can also configure Valkey to automatically rewrite its configuration file on shutdown if certain changes have been made. This is controlled by the save-on-reconfig directive in your valkey.conf. When save-on-reconfig yes, Valkey will automatically perform a CONFIG REWRITE before shutting down if any configuration parameters have been modified at runtime since the last rewrite or startup.

The most surprising thing about CONFIG REWRITE is that it doesn’t just update the specific lines you changed; it regenerates the entire configuration file from scratch based on the server’s current in-memory state. This can be a bit of a shock if you’ve made manual edits to your valkey.conf that were not applied via CONFIG SET and then CONFIG REWRITE, as those manual changes will be overwritten.

The next step after mastering persistent configuration is understanding how to manage Valkey’s persistence mechanisms like RDB snapshots and AOF logs, which handle data durability rather than configuration.

More Deep Dives in Valkey