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" --join somecluster.example.com

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.

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.

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.

By default, Swytch runs as a pure in-memory cache. Data is lost on restart but performance is maximised.

swytch redis --maxmemory=4gb

When running in a cluster (--join), data is replicated across nodes via the effects engine, so it survives individual node restarts. To also survive a full-cluster restart, connect the cluster to Swytch Cloud with --cloud. See 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 are supported via the gopher-lua interpreter. Most redis.* API calls work, but the following features are not available:

• 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
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

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.