Deployment guide

Redka

Overview

Redka is a Redis-compatible server that speaks the Redis wire protocol (RESP) and persists everything to a durable SQLite database. You connect with any Redis client, and the data lives in a plain SQLite file that you can inspect and report on with ordinary SQL.

This SecureAnyCloud image installs the Redka server (cmd/redka) 1.0.1, pinned and verified against the upstream release checksum. It runs as a dedicated redka system user, keeps its database on a dedicated Azure data disk, and listens on loopback only. Redka suits embedded caches, lightweight test environments that would otherwise need a Redis test container, and small workloads that want Redis-style data structures on a relational, inspectable backend.

What you get:

  • 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
  • A loopback-only listener on 6379, not exposed publicly
  • Per-VM connection details written on first boot
  • 24/7 SecureAnyCloud 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. Redka is a lightweight, embeddable, single-node store. 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 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.

Two command-level differences are illustrated in the steps 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

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 only. No inbound application ports are needed, because you reach Redka over an 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 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.

Select Review + create, then 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:redka:default:latest
az vm create \
  --resource-group <your-rg> \
  --name redka \
  --image sac1647283583153:redka: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

Connect over SSH as azureuser:

ssh azureuser@<vm-public-ip>

Step 4 - Confirm Redka is running

Run the checks below to confirm that Redka is installed and listening.

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. This confirms that Redka is bound to loopback only.

Each VM writes its connection details on first boot to a root-only file. Read it with sudo:

sudo cat /root/redka-connection.txt

Step 5 - Connect with redis-cli

Redka speaks the Redis wire protocol, so any Redis client works. Use the bundled redis-cli to set and read strings and hashes:

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. Remember that Redka's RPUSH and LPUSH take one element per call. 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

Everything you write over the Redis protocol is stored in a SQLite database that you can query directly. 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 in Step 5 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;"

Use the SQL layer for reading, analysis and reporting. Keep writes going through the Redis API so that 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. This 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. 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 you can resize the volume independently of the OS disk.

Redka uses SQLite in WAL mode, so redka.db-wal and redka.db-shm appear alongside the database. The shipped image contains an empty database, and each VM creates its own on first start.

Manage the Redka service like any systemd unit:

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

Support

SecureAnyCloud images come with 24/7 support. For questions about this Redka image or help with your deployment, contact us through the SecureAnyCloud website.

Deploy on Azure

Launch Redka 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