Redis as Tor Hidden Service

The critical Redis security configuration for Tor isolation: bind 127.0.0.1 in redis.conf. This restricts Redis to accept connections only from localhost. Combined with the Tor hidden service mapping (HiddenServicePort 6379 127.0.0.1:6379), Redis becomes accessible only via the .onion address through Tor. Verify the bind is effective: redis-cli -h 0.0.0.0 ping should fail (connection refused). Only redis-cli -h 127.0.0.1 ping should succeed locally. For .onion applications on the same server as Redis: connect directly to 127.0.0.1:6379 (no Tor overhead for same-server applications). For remote applications on different servers: connect via the .onion address through Tor SOCKS5 proxy. Authentication: enable Redis AUTH by setting requirepass in redis.conf with a strong random password. Redis without authentication is completely open to anyone who can connect - authentication is mandatory even when bound to localhost.

Tor adds 100-400ms latency to each Redis command over .onion. This is significant for applications that make many small Redis commands per request. Optimization strategies: (1) Redis pipelining: send multiple commands in one batch and receive all responses together. Most Redis client libraries support pipelining (redis-py in Python, ioredis in Node.js). Convert request-response pairs to pipeline batches when possible. (2) Redis Lua scripts: execute multiple Redis operations atomically server-side with EVAL. The entire script runs in one round trip regardless of operation count. (3) Data structure design: choose Redis data structures that minimize command count. Store session data as a single Redis hash (HGETALL returns all fields in one command) rather than individual keys. (4) Connection pooling: maintain persistent connection pools in the application to avoid connection overhead per operation. Tor circuit setup (3-5 seconds) is a one-time cost if the connection is kept alive via the pool.

Redis Cluster distributes data across multiple nodes for horizontal scaling. For a Tor hidden service deployment: each Redis Cluster node would need its own .onion address, and cluster protocol (gossip protocol on port 16379) needs to communicate between nodes. Configuring Redis Cluster over Tor is complex - the gossip protocol must also route through Tor. For most .onion application workloads: a single Redis instance is sufficient. Redis single instance on typical VPS hardware handles 100,000+ operations/second. The bottleneck for .onion applications is Tor latency, not Redis throughput. Only if Redis itself becomes the throughput bottleneck (which requires massive write volume) should Redis Cluster be considered for .onion deployments.

Redis offers two persistence options: RDB (point-in-time snapshots at configured intervals) and AOF (append-only file logging every write operation). For .onion hidden service Redis: enable RDB with periodic snapshots (save 900 1, save 300 10, save 60 10000 - standard defaults) for crash recovery. Enable AOF (appendonly yes) for durability at the cost of disk write overhead. With both: recovery after crash restores to the last AOF-consistent state. Backup: copy the RDB dump file (dump.rdb) and AOF file (appendonly.aof) to encrypted backup storage. Schedule via cron: redis-cli BGSAVE triggers a background save, then copy dump.rdb after completion. Transfer to off-server backup via encrypted transfer through Tor. For a distributed backup: rsync to a second .onion server using torsocks rsync.

Redis Pub/Sub enables real-time message broadcasting between application components. For a .onion application: one or more publishers send messages to Redis channels, and subscriber components receive those messages. Use cases: real-time chat messages forwarded between chat server instances, live event notifications in a community platform, and inter-service communication in a microservices .onion architecture. Configuration: no special configuration beyond standard Redis setup. The pub/sub channels operate over the same .onion connection as key-value operations. The same Tor latency considerations apply: Pub/Sub message delivery over .onion adds Tor's round-trip latency (100-400ms). For real-time applications, ensure the application UI design tolerates this latency (e.g., optimistic updates). Redis Pub/Sub is suitable for near-real-time (sub-second messaging acceptable) not hard real-time (millisecond latency required).