Redka on Ubuntu 24.04 on Azure User Guide

Overview

Redka is a Redis compatible server that speaks the Redis wire protocol (RESP) while persisting everything to a durable, queryable SQLite database. You talk to it with any Redis client, but the data lives in a plain SQLite file you can inspect and report on with ordinary SQL. It is a natural fit for embedded caches, lightweight test environments that would otherwise need a Redis test container, and small scale workloads that want Redis style data structures with a relational, inspectable backend.

The cloudimg image installs the Redka server (cmd/redka) 1.0.1, pinned and verified against the upstream release checksum, runs it as a dedicated redka system user, stores the SQLite database on a dedicated Azure data disk, binds it to loopback only, and writes per-VM connection details on first boot. Backed by 24/7 cloudimg support.

What is included:

• Redka server 1.0.1 (BSD-3-Clause), the pinned prebuilt Linux binary from the upstream GitHub release, checksum verified
• The redis-cli and sqlite3 command line tools for talking to Redka and inspecting its store
• The SQLite database on a dedicated 16 GiB Azure data disk at /var/lib/redka, captured into the image and re-provisioned on every VM
• Loopback-only listener on 6379, not exposed publicly
• Per-VM connection details written on first boot
• 24/7 cloudimg support

What Redka is, and is not

Redka implements a subset of Redis and runs as a single node. It supports the five core Redis data types (strings, lists, hashes, sets, sorted sets), key and TTL management, and a handful of server and connection commands. It does not provide clustering, replication, pub/sub, Lua scripting, streams, transactions over the wire, or the bitmap, geo and hyperloglog types. It is therefore ideal as a lightweight, embeddable, single-node store, but it is not a drop-in replacement for a Redis cluster.

Redka also has no authentication: the upstream server exposes no password or AUTH command. For that reason the cloudimg image binds Redka to 127.0.0.1 only and never exposes port 6379. Reach it locally on the VM or over an SSH tunnel; never bind it to a public interface without an external, authenticating, TLS-terminating proxy in front.

A few command level differences to be aware of, all illustrated below:

• RPUSH and LPUSH take a single element per call, not a variadic list.
• ZRANGE by rank does not accept Redis style negative indices; use positive bounds or -inf +inf BYSCORE.

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet plus 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 only. No inbound application ports are needed because Redka 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 Redka 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 then Create.

Step 2 - Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name redka \
  --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 Redka is installed and running

redka --help 2>&1 | head -1 || true
systemctl is-active redka
ss -tln | grep 6379

redka.service reports active and the only listener on 6379 is 127.0.0.1, confirming Redka is bound to loopback only.

The per-VM connection details are written on first boot to a root-only file:

sudo cat /root/redka-connection.txt

Step 5 - Connect with redis-cli and use the Redis protocol

Redka speaks the Redis wire protocol, so any Redis client works. The image ships redis-cli:

redis-cli -h 127.0.0.1 -p 6379 ping
redis-cli -h 127.0.0.1 -p 6379 set name alice
redis-cli -h 127.0.0.1 -p 6379 get name
redis-cli -h 127.0.0.1 -p 6379 hset user:1 email alice@example.com plan pro
redis-cli -h 127.0.0.1 -p 6379 hgetall user:1

Lists and sorted sets work too. Note that Redka's RPUSH/LPUSH take one element per call, and ZRANGE uses positive rank bounds or -inf +inf BYSCORE:

redis-cli -h 127.0.0.1 -p 6379 rpush tags redis
redis-cli -h 127.0.0.1 -p 6379 rpush tags sqlite
redis-cli -h 127.0.0.1 -p 6379 lrange tags 0 100
redis-cli -h 127.0.0.1 -p 6379 zadd fruit 3 pear 1 apple 2 plum
redis-cli -h 127.0.0.1 -p 6379 zrange fruit -inf +inf byscore withscores

Step 6 - Query the SQLite backing store with SQL

This is what makes Redka distinctive: everything you write over the Redis protocol is stored in, and directly queryable from, a SQLite database. Redka creates the tables rkey, rstring, rlist, rset, rhash, rzset and, for convenient reading, the views vkey, vstring, vlist, vset, vhash, vzset. The data you set above is visible immediately with ordinary SQL:

sudo sqlite3 /var/lib/redka/redka.db ".tables"
sudo sqlite3 -header -column /var/lib/redka/redka.db "select key, value from vstring;"
sudo sqlite3 -header -column /var/lib/redka/redka.db "select key, field, value from vhash;"
sudo sqlite3 -header -column /var/lib/redka/redka.db "select key, elem, score from vzset order by score;"

The SQL layer is intended for reading, analysis and reporting; keep writes going through the Redis API so Redka maintains its own consistency.

Step 7 - Secure remote access over an SSH tunnel

Port 6379 is bound to loopback only and is never opened publicly, and Redka has no authentication of its own. A redis-cli connection aimed at the VM's routable address is refused, which is the intended posture:

To reach Redka from your workstation, open an SSH tunnel and point your Redis client at the local end:

ssh -L 6379:127.0.0.1:6379 azureuser@<vm-public-ip>
# then, in another terminal on your workstation:
redis-cli -h 127.0.0.1 -p 6379 ping

Do not change the listener to 0.0.0.0 or a public interface without an external, authenticating, TLS-terminating proxy in front, because Redka itself performs no authentication.

Persistence and the data disk

The SQLite database lives at /var/lib/redka/redka.db on a dedicated 16 GiB Azure data disk mounted at /var/lib/redka. The disk is captured into the image and re-provisioned on every VM, so the keyspace survives restarts and the volume can be resized independently of the OS disk. Redka uses SQLite in WAL mode (redka.db-wal, redka.db-shm alongside the database). The shipped image contains an empty database; each VM creates its own on first start.

You can manage the Redka service like any systemd unit:

systemctl status redka
sudo systemctl restart redka
journalctl -u redka --no-pager | tail -20

Support

Every cloudimg image includes 24/7 support. If you have questions about this guide or the Redka image, contact the cloudimg team at www.cloudimg.co.uk.