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-cliandsqlite3command-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:
RPUSHandLPUSHtake a single element per call, not a variadic list.ZRANGEby 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 StandardStep 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 6379redka.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.txtStep 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:1Lists 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 withscoresStep 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 pingDo 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 -20Support
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