The problem/use-case that the feature addresses
With the automated cert provisioning, server certificates often has a short expiration time (e.g., 90 days, 30 days, or less) due to security policies.
Currently, when the certificate files (tls-cert-file, tls-key-file, and potentially tls-client-cert-file, tls-client-key-file) are renewed and replaced on the filesystem, Valkey does not automatically detect or reload them.
As mentioned in redis/redis#8756, the current workaround is to manually trigger a cert reload on each instance using CONFIG SET
This lack of automatic, built-in certificate reload functionality creates a significant operational burden and introduces potential downtime or connection errors if a certificate expires before the manual cert reload .
Description of the feature
The feature should provide a mechanism for Valkey to automatically detect and reload TLS certificate files when they are updated on the filesystem, without requiring a server restart or the use of external CONFIG SET commands.
Possible implementation ideas include:
-
File Watching: Add a background thread or mechanism to monitor the configured certificate/key/CA file paths for file system change events (e.g., inotify/fswatch).
-
Timed Check: Introduce a new configuration directive (e.g., tls-cert-reload-interval <seconds>) that specifies how often Valkey should check the certificate files' modification times and reload them if they've changed.
Upon a successful reload, the new certificate should be used for all new incoming connections immediately, while existing connections should be allowed to terminate naturally.
Alternatives you've considered
-
Current CONFIG SET Workaround: This requires an external system (e.g., a cron job or a certificate management tool's hook) to execute the CONFIG SET command after renewal. This solution is prone to errors, requires external dependencies, and is not a clean, native solution.
-
Full Server Restart: A full restart (e.g., via systemctl restart valkey) successfully loads the new certificates but causes an unnecessary service interruption, which is unacceptable in high-availability environments.
Additional information
This is a common feature in other modern network services (e.g. Envoy).
A reload mechanism that ensures both the private key and certificate files are reloaded together atomically would be ideal to prevent a race condition where a client connects with a mismatched key/certificate pair.
The problem/use-case that the feature addresses
With the automated cert provisioning, server certificates often has a short expiration time (e.g., 90 days, 30 days, or less) due to security policies.
Currently, when the certificate files (
tls-cert-file,tls-key-file, and potentiallytls-client-cert-file,tls-client-key-file) are renewed and replaced on the filesystem, Valkey does not automatically detect or reload them.As mentioned in redis/redis#8756, the current workaround is to manually trigger a cert reload on each instance using
CONFIG SETThis lack of automatic, built-in certificate reload functionality creates a significant operational burden and introduces potential downtime or connection errors if a certificate expires before the manual cert reload .
Description of the feature
The feature should provide a mechanism for Valkey to automatically detect and reload TLS certificate files when they are updated on the filesystem, without requiring a server restart or the use of external CONFIG SET commands.
Possible implementation ideas include:
File Watching: Add a background thread or mechanism to monitor the configured certificate/key/CA file paths for file system change events (e.g., inotify/fswatch).
Timed Check: Introduce a new configuration directive (e.g.,
tls-cert-reload-interval <seconds>) that specifies how often Valkey should check the certificate files' modification times and reload them if they've changed.Upon a successful reload, the new certificate should be used for all new incoming connections immediately, while existing connections should be allowed to terminate naturally.
Alternatives you've considered
Current
CONFIG SETWorkaround: This requires an external system (e.g., a cron job or a certificate management tool's hook) to execute the CONFIG SET command after renewal. This solution is prone to errors, requires external dependencies, and is not a clean, native solution.Full Server Restart: A full restart (e.g., via
systemctl restart valkey) successfully loads the new certificates but causes an unnecessary service interruption, which is unacceptable in high-availability environments.Additional information
This is a common feature in other modern network services (e.g. Envoy).
A reload mechanism that ensures both the private key and certificate files are reloaded together atomically would be ideal to prevent a race condition where a client connects with a mismatched key/certificate pair.