KeyDB on Ubuntu 24.04 on Azure User Guide

Overview

KeyDB is a high-performance fork of Redis that is fully protocol- and command-compatible but uses multiple threads to drive higher throughput from a single node. It is a drop-in replacement for Redis for caching, session stores, queues, rate limiting, leaderboards and pub/sub. The cloudimg image installs KeyDB 6.3.4 (the official keydb-server + keydb-cli from the KeyDB package repository), runs it as a dedicated keydb system user, stores RDB snapshots and the AOF append-only log on a dedicated Azure data disk, and rotates a unique password into the image on first boot. Backed by 24/7 cloudimg support.

What is included:

• KeyDB 6.3.4 (keydb-server + keydb-cli) from the official KeyDB packages
• Multithreaded engine (server-threads 2) to use both vCPUs of a Standard_B2s
• A unique per-VM password generated on first boot (no shared default credential)
• RDB snapshots and AOF persistence on a dedicated 16 GiB Azure data disk at /var/lib/keydb
• Loopback-only listener on 6379 with requirepass authentication (not exposed publicly)
• 24/7 cloudimg support

This is a datastore product: KeyDB listens on 127.0.0.1:6379 only. The port is not opened to the internet - connect locally on the VM or over an SSH tunnel.

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet + subnet in the target region. Standard_B2s (2 vCPU / 4 GiB RAM) is a good starting point. NSG inbound: allow 22/tcp from your management network. No inbound application ports are needed because KeyDB is reached over the SSH tunnel.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for KeyDB by cloudimg, and select Create. On Basics pick your subscription, resource group, region and size; under Administrator account choose SSH public key and paste your key; under Inbound port rules allow SSH (22) only. Then Review + create -> Create.

Step 2 - Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name keydb \
  --image <marketplace-image-urn> \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard

Step 3 - Connect to your VM

ssh azureuser@<vm-public-ip>

Step 4 - Confirm KeyDB is installed and running

keydb-server --version
systemctl is-active keydb-server

You should see KeyDB v=6.3.4 and active:

KeyDB server v=6.3.4 sha=00000000:0 malloc=jemalloc-5.2.1 bits=64 build=b532cd0401cb0da4
active

Step 5 - Retrieve your per-VM password

Each VM generates its own unique KeyDB password on first boot and writes it to a root-only credentials file:

sudo cat /root/keydb-credentials.txt

The file contains KEYDB_PASSWORD, the connection string and the SSH-tunnel instructions. Store the password in your secrets manager. In the commands below, <KEYDB_PASSWORD> stands for the value of KEYDB_PASSWORD.

Step 6 - Authenticate with keydb-cli

KeyDB requires the password (requirepass). Authenticate and run a PING:

keydb-cli -a <KEYDB_PASSWORD> --no-auth-warning ping

PONG

A wrong password is rejected with WRONGPASS, so the datastore is never open without the credential.

Step 7 - Store and retrieve data

KeyDB speaks the Redis protocol, so every Redis command works unchanged. Set a string, read it back, increment a counter and push to a list:

keydb-cli -a <KEYDB_PASSWORD> --no-auth-warning set greeting "hello from KeyDB"
keydb-cli -a <KEYDB_PASSWORD> --no-auth-warning get greeting
keydb-cli -a <KEYDB_PASSWORD> --no-auth-warning set counter 100
keydb-cli -a <KEYDB_PASSWORD> --no-auth-warning incr counter
keydb-cli -a <KEYDB_PASSWORD> --no-auth-warning rpush mylist a b c
keydb-cli -a <KEYDB_PASSWORD> --no-auth-warning lrange mylist 0 -1

OK
hello from KeyDB
OK
101
3
a
b
c

Step 8 - Confirm persistence and multithreading

KeyDB persists data with AOF (append-only file) plus periodic RDB snapshots, both on the dedicated data disk at /var/lib/keydb. Confirm the keyspace, that AOF is enabled, and the server details:

keydb-cli -a <KEYDB_PASSWORD> --no-auth-warning info keyspace
keydb-cli -a <KEYDB_PASSWORD> --no-auth-warning info persistence | grep aof_enabled
keydb-cli -a <KEYDB_PASSWORD> --no-auth-warning info server | grep -E 'redis_version|executable|config_file'

# Keyspace
db0:keys=3,expires=0,avg_ttl=0,cached_keys=3
aof_enabled:1
redis_version:6.3.4
executable:/usr/bin/keydb-server
config_file:/etc/keydb/keydb.conf

aof_enabled:1 confirms durable persistence. KeyDB runs multiple server threads (configured with server-threads 2); you can see them with:

ps -L -p "$(pgrep -x keydb-server | head -1)" -o comm= | sort | uniq -c

Step 9 - Connect remotely over an SSH tunnel

KeyDB listens on 127.0.0.1:6379 only and is not exposed publicly - this is the secure default. To reach it from your workstation, open an SSH tunnel and point a local client at localhost:6379:

# On your workstation:
ssh -L 6379:127.0.0.1:6379 azureuser@<vm-public-ip>

# In another terminal, with a local keydb-cli or redis-cli:
keydb-cli -h 127.0.0.1 -p 6379 -a <KEYDB_PASSWORD> --no-auth-warning ping

The authentication round-trip below proves the wall: the wrong password is rejected, the correct one is accepted.

For production remote access without a tunnel, bind KeyDB to a private NIC and front it with TLS (for example via stunnel or a service mesh). Never expose 6379 to the internet without transport encryption.

Maintenance

• Persistence: RDB snapshots and the AOF log live on the dedicated data disk at /var/lib/keydb, so the keyspace survives reboots and the volume is independently resizable.
• Password: change it by editing requirepass in /etc/keydb/keydb-firstboot.conf and running sudo systemctl restart keydb-server.
• Tuning: edit /etc/keydb/keydb.conf (for example maxmemory, maxmemory-policy, server-threads) and restart the service.
• Security patches: unattended-upgrades remains enabled so the OS continues to receive security updates automatically.
• Compatibility: KeyDB is a Redis drop-in - existing Redis clients, libraries and tooling work unchanged against 6379.

Support

cloudimg provides 24/7 expert support for this image. Contact support@cloudimg.co.uk.

KeyDB is a trademark of Snap Inc. Redis is a trademark of Redis Ltd. This image is provided by cloudimg and is not affiliated with or endorsed by Snap Inc. or Redis Ltd.