Redis Commands and CLI

Look up supported commands, command-line flags, and compatibility differences. For your first connection, use the Kubernetes quickstart or compatibility overview. For application examples, use the data structure guides.

# Start with defaults (64MB memory, port 6379)
swytch redis

# Production setup with 4GB memory
swytch redis --maxmemory=4gb --bind=0.0.0.0

# Production setup with metrics
swytch redis --maxmemory=4gb --bind=0.0.0.0 --metrics-port=9090

# Join a cluster
swytch redis --bind=0.0.0.0 --cluster-passphrase="YOUR_PASSPHRASE" \
  --cluster-port 7379 \
  --cluster-advertise 10.0.0.2:7379 \
  --join 10.0.0.1:7379

Development builds expose CONFIG SET|GET cluster_safe_mode and CONFIG SET|GET key_safe_mode for cluster and per-key safety policies, including Redis glob patterns such as sessions::*.

Swytch implements a comprehensive set of Redis commands across all major data types.

RedisJSON commands are built in. Use them to read and update structured documents by path.

See JSON documents for examples and path behavior.

By default, commands inside MULTI return QUEUED. Start with swytch redis --ssi for immediate results on the transaction snapshot, including its earlier writes. Make decisions in application code, then commit with EXEC. EXEC returns the collected results without rerunning commands; a confirmed conflict returns null. Use one connection and retry the entire transaction after a confirmed abort. See real transactions for client examples, error handling, and commands that cannot run inside SSI.

Lua scripts and functions are provided on a best-effort basis for Redis compatibility. Lua is not required to write transactional application logic in Swytch; SSI transactions are recommended for new code.

Note: There is no --maxmemory-policy flag. Swytch uses a self-tuning frequency-based eviction algorithm that automatically adapts to your workload. See Eviction Policy below.

This startup flag applies to connections to the server. Redis transaction helpers that require QUEUED replies need adaptation. See SSI client usage.

This startup flag is also available on swytch sql. It is not a Redis CONFIG SET parameter. Each process needs a separate directory. See local durability for setup, sync timing, and the destructive fallback when recovery cannot fit the memory budget.

Both --tls-cert-file and --tls-key-file must be specified together. Adding --tls-ca-cert-file enables mutual TLS, requiring clients to present a certificate signed by the given CA.

--join requires --cluster-passphrase. --cloud is mutually exclusive with both. See the Deployment guide for clustering and Swytch Cloud setup.

See the Observability guide for details on all available metrics and tracing.

Without --data-dir, Swytch keeps its local state in memory. A standalone process starts empty after a restart.

swytch redis --maxmemory=4gb

A surviving subscriber may retain a key after a clustered node restarts; adding peers does not automatically copy every key. Enable local durability to restore synced resident effects from that node’s disk:

swytch redis --maxmemory=4gb --data-dir=/var/lib/swytch

Eviction removes unreferenced mirror records. Writes return before file syncing completes; the oldest unsynced write sets a 10 ms scheduling deadline. If recovery exceeds its memory budget, Swytch warns and waits 30 seconds before deleting the mirror and starting empty unless stopped. Use Swytch Cloud for a network storage tier, and the deployment guide for cluster setup.

Redis Cluster commands are not supported. Swytch is designed for appearing as a single-node Redis instance, even while clustered.

Replication commands (SYNC, PSYNC, REPLCONF, WAIT) are stubbed but non-functional. There is no master/replica support.

Swytch includes the RedisJSON JSON.* command family directly in the server; no separate JSON module installation is required. See JSON commands and the JSON guide. Check other module requirements individually rather than assuming support from Redis protocol compatibility.

• OBJECT - Object introspection is not implemented
• DEBUG - Most debug subcommands not implemented
• SLOWLOG - Slow query log not implemented
• LATENCY - Latency monitoring not implemented
• CLIENT PAUSE/UNPAUSE - Not implemented
• CLUSTER * - All Redis Cluster commands (Swytch uses its own clustering model)

Swytch uses a self-tuning frequency-based eviction algorithm instead of Redis’s configurable LRU/LFU policies. This typically results in better hit rates without manual tuning.

Memory usage statistics may differ from Redis due to different internal data structures and Go’s memory allocator.

Lua scripts and functions have best-effort compatibility support through the gopher-lua interpreter. They are optional: Swytch’s SSI transactions let you read, decide, and write in application code without a Lua script. Prefer SSI for new transactional logic, and test any existing scripts you retain against the version you deploy.

The following Lua compatibility limits apply:

• cjson - JSON encoding/decoding (cjson.encode, cjson.decode) is not implemented
• cmsgpack - MessagePack serialization is not implemented
• redis.sha1hex () – SHA1 hashing helper is not implemented
• bit.tohex – Has a known bug with certain edge cases

If you encounter other incompatibilities, please report them at the issue tracker.

Swytch is single-database only. SELECT 0 is accepted for client compatibility; any other index returns an error, as do SWAPDB and MOVE. Use a separate Swytch instance if you need multiple databases.

Swytch supports Redis-compatible ACLs for fine-grained user authentication and authorization.

Create an ACL file and pass it with --aclfile:

swytch redis --aclfile /etc/swytch/users.acl

The file contains one user definition per line:

# Default user with full access and a password
user default on >mypassword ~* &* +@all

# Read-only user for monitoring
user monitor on >monpass ~* &* +@read -@write -@admin

# Application user with access to specific key prefixes
user myapp on >apppass ~app:* ~session:* &* +@all -@admin

# Disabled user
user old_user off

# Connect with redis-cli
$ redis-cli -p 6379

# Basic operations
127.0.0.1:6379> SET mykey "Hello World"
OK
127.0.0.1:6379> GET mykey
"Hello World"

# With expiration
127.0.0.1:6379> SETEX session:123 3600 "user-data"
OK
127.0.0.1:6379> TTL session:123
(integer) 3600

# Lists
127.0.0.1:6379> RPUSH mylist a b c
(integer) 3
127.0.0.1:6379> LRANGE mylist 0 -1
1) "a"
2) "b"
3) "c"

# Hashes
127.0.0.1:6379> HSET user:1 name "Alice" age 30
(integer) 2
127.0.0.1:6379> HGETALL user:1
1) "name"
2) "Alice"
3) "age"
4) "30"

# Transactions in default mode (without --ssi)
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> INCR counter
QUEUED
127.0.0.1:6379> INCR counter
QUEUED
127.0.0.1:6379> EXEC
1) (integer) 1
2) (integer) 2

For immediate replies and application-side decisions, start with --ssi and follow the SSI transaction walkthrough.

Enable Prometheus metrics for monitoring:

swytch redis --metrics-port=9090

Scrape metrics from http://localhost:9090/metrics.

Use the standard Redis INFO command for server statistics:

redis-cli INFO

Check the Swytch version:

# CLI version
swytch --version

# Server version (via redis-cli)
redis-cli INFO server | grep redis_version
# Returns: redis_version:8.4.0-swytch

Swytch handles POSIX signals for graceful shutdown:

For container orchestration (Kubernetes, Docker), send SIGTERM to gracefully stop the server. Swytch will:

1. Stop accepting new connections
2. Complete in-flight commands
3. Shut down cluster connections (if clustered)
4. Exit cleanly

There is no drain period configuration; shutdown completes as fast as pending work allows.