Valkey

Ghayma runs managed Valkey 9.1, an in-memory key-value store. It is Redis-compatible: every Redis client works with it. Use it for caches, sessions, queues, rate limits and pub/sub.

Create one

In the console , open Databases → New, pick the Valkey card, then choose Cache or Store (see Cache or store). From the CLI:

ghayma db create cache --type valkey --mode store

Leave out --mode for a cache. Choose the apps that use it with --site, as for any database — see ghayma db create.

• It runs on every tier, xs included. It is priced like the other engines: tier points, disk and backup schedule. See Pricing by Service.
• It is running once it answers. The sites you chose at create connect at that moment; until then they wait.
• A Valkey that never becomes ready is in error, and says why. The console’s database header and ghayma db info show the reason next to the status.

Cache or store

A Valkey runs in one of two modes:

The database page’s header shows the mode as a Cache or Store chip. Switch modes at any time while the database runs:

• Console: the database’s Settings → Valkey mode, then confirm the switch.
• CLI: ghayma db mode. The cache database created above in store mode moves to cache mode:

ghayma db mode cache cache

⏳ Switching cache to cache mode. It restarts: a few seconds of downtime...
✅ cache is in cache mode: evicts the least-recently-used keys when memory is full. Snapshots only.

The switch restarts the database: a few seconds of downtime. Moving to store writes the append-only file first, which takes longer on a large dataset. Moving to cache takes a fresh snapshot first.

Memory and disk

Valkey keeps its data in memory. Its maxmemory is 70 % of the tier’s memory limit; the rest is headroom for snapshots and client buffers.

• In store mode, a full memory refuses writes. Commands that add data fail with an out-of-memory (OOM) error until you delete keys or move to a bigger tier.
• A new tier restarts the database with the new limit. Change it in the console (Settings → Resize database) or with ghayma db resize cache --tier m.
• The disk holds the snapshots and the append-only file. It is sized in GB, 1 GB at least, and grows online. It cannot shrink yet.

Connecting an app

Connect a site as you would to any database: the Access list on the database’s Connection tab in the console, or the CLI:

ghayma connect database cache --site main

Only a running Valkey can be connected. Before that, the connect is refused:

❌ cache is not running, so no app can connect to it yet. Start it if it is stopped (ghayma db start cache), or wait until ghayma db info cache shows running.

The app receives REDIS_URL and VALKEY_URL, both holding the same URL:

redis://c_<id>:<password>@<host>:6379/0

• The oldest Valkey the app is connected to gets the plain names. Every Valkey also gets names of its own, REDIS_URL_<NAME> and VALKEY_URL_<NAME>, built from the database name as described in One set of variables per database.
• Each app has its own user. The c_… user in the URL was created for that one connection. There is no shared password, and disconnecting an app deletes only its user.
• The level decides what the user may run. connect allows every data command, including FLUSHALL, KEYS and pub/sub, but no administrative command such as CONFIG or ACL. read-only allows reads and SUBSCRIBE. See Read-only connections.

Rotate one app’s password without touching the others:

ghayma connections rotate database cache --site main

Rotating also needs the database running:

❌ cache is not running, so this app's password cannot be rotated now. Start it if it is stopped, or wait until ghayma db info cache shows running.

See Rotating Credentials.

In your code, read REDIS_URL.

Node.js (ioredis):

import Redis from 'ioredis'
 
const redis = new Redis(process.env.REDIS_URL)

Python (redis):

import os
import redis
 
r = redis.from_url(os.environ["REDIS_URL"])

PHP / Laravel: config/database.php reads it in redis.default.url:

'redis' => [
    'default' => [
        'url' => env('REDIS_URL'),
    ],
],

Builds

The Valkey variables are runtime only. A build never receives them, because builds cannot reach the database. A build-time variable you set yourself, such as your own REDIS_URL, stays in the build; the running app gets the platform’s value.

From your machine

ghayma connect --local tunnels the app’s databases to this machine. A Valkey answers on 127.0.0.1:16379, or the next free port if that one is taken, and .env.local carries that address:

🔌 Tunnel open for 'main' — its databases answer on this machine:
   cache (valkey) → 127.0.0.1:16379
   Wrote 8 variables to .env.local (hosts point at the listeners; restore with: ghayma env pull)
   Leave this running; Ctrl-C closes the tunnel.

In a second terminal, with REDIS_URL from .env.local loaded in your shell:

redis-cli -u "$REDIS_URL" PING

Backups and restore

Scheduled and manual backups are encrypted snapshots, on the same schedules as the other engines. Take one or restore one from the database’s Backups tab in the console.

A restore stops the database, swaps in the backup’s data and starts it again: a few seconds of downtime.

Logs

Read the database’s own log in the console’s Logs tab. Pick how many Lines to show (100, 200, 500 or 1000) and turn on Follow to watch new lines arrive; a follow stays open for up to 10 minutes. From the CLI, use ghayma db logs:

ghayma db logs cache -n 500
ghayma db logs cache -f

Every engine has it, not only Valkey.

Not available yet

• Public access from the internet. Planned. Use the tunnel instead: ghayma connect --local.
• A key browser in the console. Read and change keys with redis-cli through the tunnel.
• Shrinking the disk. The disk only grows. Start small: it grows online when you need more.