Documentation

Redis gateway

Standard Redis clients speak RESP, a binary-safe, request-response wire protocol over TCP (RESP2 by default, RESP3 via the HELLO handshake). Cacheify runs a RESP gateway so your existing Redis client code connects to a Cacheify database unchanged.

redis:// and rediss:// RESP2 + RESP3 AUTH = API key

Connect

The whole connection is one line:

Connection string — any native Redis client

redis://:<your-key>@node18.botkeep.cloud:61350/0

The password slot holds the database's active API key and the database is always 0 — SELECT is accepted for compatibility but cannot switch databases: one Cacheify database is one virtual Redis database, fixed by the AUTH key.

First commands

The string above lives in your REDIS_URL environment variable:

redis-cli

$REDIS_URL="redis://:<your-key>@<gateway-host>:<port>/0"

redis-cli -u "$REDIS_URL" set greeting hello         # OK — inherits 24h TTL
redis-cli -u "$REDIS_URL" get greeting               # "hello"
redis-cli -u "$REDIS_URL" set otp:user@mail.com abc EX 300

Node.js (ioredis)

const Redis = require('ioredis');
const redis = new Redis(process.env.REDIS_URL);

await redis.set('greeting', 'hello');                  // inherits the 24h TTL
await redis.get('greeting');                           // "hello"
await redis.setex('otp:user@mail.com', 300, otpHash);  // explicit 5 minutes

Python (redis-py)

import os, redis

conn = redis.Redis.from_url(os.environ["REDIS_URL"], decode_responses=True)

conn.set("greeting", "hello")                      # inherits the 24h TTL
conn.get("greeting")
conn.setex("otp:user@mail.com", 300, otp_hash)     # explicit 5 minutes

Behavior you can rely on

Works like real Redis	Notes
SET / GET / INCR / EXPIRE / DEL / TYPE / EXISTS / TTL …	Same reply shapes, same error prefixes (ERR, WRONGTYPE).
Strings, lists, sets, hashes, sorted sets	Same command surface as the dashboard Console.
Pipelining	Clients may send commands without waiting; replies come in order (the documented RESP request-response model).
KEYS / SCAN	Bounded SCAN loop server-side — patterns never leave your tenant namespace.
EX / SETEX / EXPIRE / PEXPIRE	Server arms a real TTL; writes without one inherit the 24-hour platform default.

Not supported (documented, by design)

Transactions and blocking verbs: MULTI/EXEC/ WATCH, BLPOP/BRPOP/ BRPOPLPUSH — these hold a long-lived session state that conflicts with per-request isolation and quotas. They answer -ERR unknown command with nothing executed, exactly like Redis does for any verb it does not know.
Pub/sub: SUBSCRIBE — the connection would switch to the Redis push model, which the gateway does not forward.
Lua: EVAL — scripts run without per-command argument checks.
PERSIST — refused with an error; no key may lose its TTL (see the TTL policy).

TLS (rediss://)

The gateway serves plain redis://; when the operator installs a certificate pair it speaks rediss://. Nothing changes in your client code except the scheme in the connection string.