Skip to main content
  1. Posts/

Valkey as Redis replacement for Nextcloud

·884 words·5 mins· 0
Nextcloud self-hosted
Table of Contents

Preamble #

Why? #

On march 20, 2024 the company Redis Inc. announed a change of the license model in a Blog post. Until the mentioned announcement above, Redis was released under the BSD-3-Clause license. All newer Releases (from version 7.4) will be released under a dual license model Redis Source Available License 2.0 (RSALv2) and Server Side Public License (SSPL).

Effects #

Versions of Redis from 7.4 must not be used for free, if they are offered or deployed in a commercial context. This includes own software products, but also professional services and hosting of Redis. The internal usage inside your company is still freely permitted.

Excerpt from the Redis Blog post:

  1. Can I host Redis as a service internal to my organization?

Yes. The terms of the RSALv2 or SSPLv1 allow for all non-production and production usage, except for providing competitive offerings to third parties that embed or host our software. Hosting the products for the internal use of your organization is permitted. An organization includes its affiliates and subsidiaries. This means one division can host Redis for use by another internal division

Alternatives #

Shortly after the publication of the Blog post multiple forks has been released or created:

In this article we take a look at Valkey. Valkey is supported by the Linux Foundation, as well as some former Redis maintainers who work for large cloud providers.

Source: heise online

Installation #

As of this writing, there are no packaged variants of Valkey. Hence, the installation is only possible by compiling the source code. The following steps have been done and tested with Debian 12.5.

Warning! The source code comes from the default unstable branch of the git repository. The usage in a production environment is currently not recommended!

Dependencies #

In the following steps, all required packages to download and compile Valkey are going to be installed

# Install build dependencies
apt install build-essential tcl pkg-config git
# (optional) packages for TLS support
apt install libssl-dev tcl-tls
# packages for systemd Support
apt install libsystemd-dev

Valkey #

Now the source code is going to be downloaded compiled

# get the source code
git clone https://github.com/valkey-io/valkey.git /opt/valkey

# change directory to downloaded source code
cd /opt/valkey

Now Valkey is actually going to be compiled. The additional parameter BUILD_TLS=yes is only required, if Valkey should support TLS

# build Valkey with TLS support and systemd support
make BUILD_TLS=yes USE_SYSTEMD=yes
# test compiled source code
## if compiled without TLS support:
make test

## if compiled with TLS support:
./utils/gen-test-certs.sh
./runtest --tls

If the tests are completed successfully, the binaries are going to be made available system-wide. These are located in /usr/local/bin/

make install

Systemd Service #

So that Valkey starts automatically after a server restart, a new file is created at the following path: /etc/systemd/system/valkey-server.service

[Unit]
Description=Valkey server
After=network.target
Documentation=https://valkey.io/

[Service]
Type=notify
ExecStart=/usr/local/bin/valkey-server /etc/valkey/valkey.conf --supervised systemd --daemonize no
PIDFile=/run/redis/redis-server.pid
TimeoutStopSec=0
Restart=always
User=redis
Group=redis
RuntimeDirectory=valkey
RuntimeDirectoryMode=2755

UMask=007
PrivateTmp=true
LimitNOFILE=65535
PrivateDevices=true
ProtectHome=true
ProtectSystem=strict
ReadWritePaths=-/var/lib/redis
ReadWritePaths=-/var/log/redis
ReadWritePaths=-/var/run/redis

CapabilityBoundingSet=
LockPersonality=true
MemoryDenyWriteExecute=true
NoNewPrivileges=true
PrivateUsers=true
ProtectClock=true
ProtectControlGroups=true
ProtectHostname=true
ProtectKernelLogs=true
ProtectKernelModules=true
ProtectKernelTunables=true
ProtectProc=invisible
RemoveIPC=true
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
RestrictNamespaces=true
RestrictRealtime=true
RestrictSUIDSGID=true
SystemCallArchitectures=native
SystemCallFilter=@system-service
SystemCallFilter=~ @privileged @resources

# valkey-server can write to its own config file when in cluster mode so we
# permit writing there by default. If you are not using this feature, it is
# recommended that you remove this line.
ReadWriteDirectories=-/etc/valkey

# This restricts this service from executing binaries other than valkey-server
# itself. This is really effective at e.g. making it impossible to an
# attacker to spawn a shell on the system, but might be more restrictive
# than desired. If you need to, you can permit the execution of extra
# binaries by adding an extra ExecPaths= directive with the command
# systemctl edit valkey-server.service
NoExecPaths=/
ExecPaths=/usr/local/bin/valkey-server /usr/lib /lib

[Install]
WantedBy=multi-user.target
Alias=valkey.service

The new unit file has to be registered in the system:

systemctl daemon-reload
Notice: The systemd unit file mentioned above, is based on the Redis unit file packaged for Debian. More modifications can be made to match Valkey, but you might have then to modify the settings of connected services.

Finally some directories are being created, to store the configuration of Valkey and to be able to create sockets and PID files:

mkdir /etc/valkey /var/run/redis

# copy existing Redis configuration into valkey configuration folder
cp /etc/redis/redis.conf /etc/valkey/valkey.conf

# allow redis user to access Valkey configutation directory and Redis Socket/PID file directory
chown -R redis: /etc/valkey /var/run/redis

Now Redis is going to be stopped and disabled. Afterwards, Valkey gets started and configured to start automatically

systemctl stop redis-server.service
systemctl disable redis-server.service

systemctl enable valkey-server.service
systemctl start valkey-server.service

Since all configuration parameters of the existing Redis instance can be adopted, there shouldn’t be any further changes required.

Test #

Once all of the above steps have been completed, the use of Valkey can be checked. In the following example we connect to a local Valkey service

valkey-cli
# authenticate, if authentication is configured in your valkey.conf file
AUTH YOUR-USER YOUR-PASSWORD

MONITOR

If you now use a connected service, you should see the accesses.

Summary #

Valkey source directory:        /opt/valkey/
Valkey config directory:        /etc/valkey/
Valkey unit file:               /etc/systemd/system/valkey-server.service
Valkey unit name:               valkey-server.service

executing user:                 redis
executing group:                redis

PID file directory:             /var/run/redis/
Socket file directory:          /var/run/redis/
Log directory:                  /var/log/redis/
Database directory:             /var/lib/redis/