Deployment guide

KeyDB

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.

This SecureAnyCloud image installs KeyDB 6.3.4 and runs it as a dedicated keydb system user. Data is stored on a dedicated Azure data disk, and a unique password is set on first boot.

What you get:

KeyDB 6.3.4 (keydb-server + keydb-cli) from the official KeyDB package repository
Multithreaded engine (server-threads 2) to use both vCPUs of a Standard_B2s
A unique per-VM password generated on first boot, with no shared default credential
RDB snapshots and the AOF append-only log 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 SecureAnyCloud 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

You need an active Azure subscription, an SSH key pair, and a VNet with a subnet in the target region.

Standard_B2s (2 vCPU / 4 GiB RAM) is a good starting size.

In the network security group (NSG), allow inbound 22/tcp from your management network. No inbound application ports are needed, because you reach KeyDB 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 SecureAnyCloud, and select Create.

On the Basics tab, 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 select Review + create and Create.

Step 2 - Deploy from the Azure CLI

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:keydb-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name keydb \
  --image sac1647283583153:keydb-ubuntu-24-04:default:latest \
  --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. Read the file with sudo:

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, then 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. Check the keyspace, confirm that AOF is enabled, and review 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. List 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 shows the access control working: the wrong password is rejected and the correct one is accepted.

For production remote access without a tunnel, bind KeyDB to a private NIC and put TLS in front of it, for example with 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 can be resized independently.
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 or server-threads) and restart the service.
Security patches: unattended-upgrades stays enabled, so the OS keeps receiving security updates automatically.
Compatibility: KeyDB is a drop-in replacement for Redis. Existing Redis clients, libraries and tooling work unchanged against 6379.

Support

SecureAnyCloud provides 24/7 expert support for this image. Contact sales@secureanycloud.com.

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

Deploy on Azure

Launch KeyDB on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Deploy on Azure

Overview

KeyDB is a high-performance, fully open source fork of Redis that adds multithreading. A single node can use all of the cores on your instance and serve far more operations per second than single-threaded Redis on the same hardware. KeyDB speaks the Redis protocol and is a drop-in replacement for Redis, so your existing Redis clients, libraries and tooling work unchanged.

This SecureAnyCloud image installs KeyDB from the official project package and runs it under the bundled keydb-server systemd service.

What you get:

A database that listens on port 6379 on all interfaces, with password authentication enforced and append-only file persistence enabled
A persistence directory at /var/lib/keydb, on a dedicated, independently resizable EBS data volume that holds the append-only file and the RDB snapshots
A fresh strong password generated on the first boot of every deployed instance, so two instances launched from the same Amazon Machine Image never share a password. KeyDB ships with no password by default.
That password set as the KeyDB requirepass and written to /root/keydb-credentials.txt with mode 0600, so that only the root user can read it
A database that refuses unauthenticated connections

Prerequisites

Before you deploy this image, make sure you have:

An Amazon Web Services account where you can launch EC2 instances
IAM permissions to launch instances, create security groups and subscribe to AWS Marketplace products
An EC2 key pair in the target Region for SSH access to the instance
A VPC and subnet in the target Region, with a security group that allows inbound port 22 from your management network and port 6379 from the application hosts that need database access
The AWS CLI (version 2) installed locally, if you plan to deploy from the command line

Launch the Instance from the AWS Marketplace

Sign in to the AWS Management Console, open the EC2 service and select Launch instance. Under Application and OS Images, choose AWS Marketplace AMIs and search for KeyDB. Select the SecureAnyCloud listing and choose Select, then Continue on the subscription summary.

Pick an instance type of m6i.large or larger, so that the multithreaded engine has cores to use. Choose your EC2 key pair under Key pair (login).

Under Network settings, select your VPC and subnet. Create or select a security group that opens port 22 from your management network and port 6379 from your application hosts. Leave the root volume at the default size or larger.

Select Launch instance. First-boot initialisation takes a few seconds after the instance state becomes Running and the status checks pass.

Launch the Instance from the AWS CLI

The command below launches an instance from the SecureAnyCloud KeyDB Marketplace AMI into an existing subnet and security group. Replace the values in angle brackets as follows:

<ami-id>: the AMI ID shown on the Marketplace listing
<key-name>: your EC2 key pair name
<subnet-id>: your subnet ID
<security-group-id>: a security group that opens ports 22 and 6379 as described above

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type m6i.large \
  --key-name <key-name> \
  --subnet-id <subnet-id> \
  --security-group-ids <security-group-id> \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=keydb}]'

When the instance reaches the Running state and its status checks pass, note its public IP address or DNS name from the EC2 console or with aws ec2 describe-instances.

Connect to Your Instance

Connect over SSH using your key pair and the login user for your operating system variant.

OS variant SSH login user

Ubuntu 24.04 ubuntu

ssh -i <key-name>.pem ubuntu@<public-ip>

Retrieve the Password

The KeyDB password is unique to your instance and was generated on first boot. Read it as root:

sudo cat /root/keydb-credentials.txt

The file lists the connection string, the host and port, and the generated password. Keep this password somewhere safe.

Confirm KeyDB Is Running

Over SSH, confirm the database service is active and listening on port 6379:

sudo systemctl is-active keydb-server
sudo ss -tlnp | grep 6379

The service is reported as active and KeyDB is listening on 0.0.0.0:6379.

To confirm the installed version and server details, use the bundled CLI. Read the generated password and run an authenticated INFO server:

PASS=$(sudo grep '^keydb.admin.pass=' /root/keydb-credentials.txt | cut -d= -f2-) keydb-cli -a "$PASS" --no-auth-warning INFO server | head -20

Connect with the KeyDB CLI

KeyDB enforces password authentication, so it rejects an unauthenticated command. Confirm this, then connect with the generated password:

PASS=$(sudo grep '^keydb.admin.pass=' /root/keydb-credentials.txt | cut -d= -f2-) keydb-cli -a "$PASS" --no-auth-warning PING

The authenticated PING returns PONG. The bundled keydb-cli is fully compatible with redis-cli, so all the usual flags and commands work.

The Redis Data Model

KeyDB supports the full Redis data model. This authenticated round trip exercises strings, counters, lists and hashes, and confirms that the data set is being stored:

PASS=$(sudo grep '^keydb.admin.pass=' /root/keydb-credentials.txt | cut -d= -f2-) keydb-cli -a "$PASS" --no-auth-warning SET session:42 user-jordan keydb-cli -a "$PASS" --no-auth-warning GET session:42 keydb-cli -a "$PASS" --no-auth-warning INCR page:views keydb-cli -a "$PASS" --no-auth-warning LPUSH queue:jobs job-a job-b job-c keydb-cli -a "$PASS" --no-auth-warning LRANGE queue:jobs 0 -1 keydb-cli -a "$PASS" --no-auth-warning DBSIZE keydb-cli -a "$PASS" --no-auth-warning DEL session:42 page:views queue:jobs

Connect from Your Application

KeyDB speaks the Redis protocol on port 6379, so any Redis client library works without code changes. Point your client at the instance public IP on port 6379. Authenticate with the generated password, using the AUTH command or the password field of your client configuration.

For example, a Redis connection URL is redis://:<password>@<instance-public-ip>:6379/.

Because KeyDB is bound to all interfaces, restrict access at the network layer. Open port 6379 in the security group only to the hosts and CIDRs that need database access, and keep it closed to the public internet.

The Data Volume

The KeyDB persistence directory lives on a dedicated EBS volume mounted at /var/lib/keydb. This keeps the append-only file and the RDB snapshots off the operating system disk and lets you resize or snapshot them independently. Confirm the mount:

df -h /var/lib/keydb

To grow the data store, expand the EBS volume in the AWS console. Then grow the filesystem on the instance with sudo resize2fs on the underlying device.

Append-only file persistence is enabled by default (appendonly yes), so writes are durable across a restart. Periodic RDB snapshots are also taken.

Enable TLS

By default, KeyDB serves the Redis protocol over plain TCP on port 6379. Enable TLS for any traffic that leaves your trusted network. KeyDB supports TLS natively.

Generate or obtain a certificate and key. Set the tls-port, tls-cert-file, tls-key-file and tls-ca-cert-file directives in /etc/keydb/keydb.conf, then restart the service. Connect TLS-aware clients to the TLS port.

Restrict the security group so that the database port is reachable only from the networks that need access.

Backup and Maintenance

Back up the database by snapshotting the /var/lib/keydb EBS volume, which captures the append-only file and the RDB snapshots. You can also trigger a save with an authenticated keydb-cli BGSAVE or keydb-cli BGREWRITEAOF.

Apply operating system security updates with sudo apt-get update && sudo apt-get upgrade, and reboot when a new kernel is installed. KeyDB starts automatically on boot.

Support

SecureAnyCloud publishes and supports this image. Support covers deployment, client configuration, persistence and durability tuning, memory and eviction policy, multithreading, replication and TLS. Contact SecureAnyCloud through the support channel listed on the AWS Marketplace listing.

All product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.

Deploy on AWS

Launch KeyDB on AWS with 24/7 support from SecureAnyCloud.

View on Marketplace

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Deploy on AWS