Installation Overview

Redis runs on Linux, macOS, and Windows (via WSL or Docker). Production deployments typically use Linux with systemd, a hardened redis.conf, and Redis 7.x for the latest ACL, TLS, and Sharded Pub/Sub features.

Choose your path:

Environment Recommended Method
Development (macOS) Homebrew
Development (Linux) apt or official packages
Production Official repo packages or Docker with persistent volumes
Windows WSL2 + apt, or Docker

Linux — Ubuntu/Debian 

  sudo apt update
sudo apt install redis-server

# Verify version
redis-server --version

# Start and enable
sudo systemctl start redis-server
sudo systemctl enable redis-server
sudo systemctl status redis-server

Default config: /etc/redis/redis.conf

Linux — CentOS/RHEL/Rocky 

  sudo yum install epel-release -y
sudo yum install redis -y

sudo systemctl start redis
sudo systemctl enable redis
redis-cli ping
# PONG

For latest Redis 7 on RHEL-based systems, use the official Redis repository or compile from source.

macOS (Homebrew) 

  brew install redis
brew services start redis

# Or run in foreground for debugging
redis-server /opt/homebrew/etc/redis.conf

Config location (Apple Silicon): /opt/homebrew/etc/redis.conf

Docker 

  # Basic development container
docker run -d --name redis \
  -p 6379:6379 \
  redis:7-alpine

# Production-style with persistence and password
docker run -d --name redis \
  -p 6379:6379 \
  -v redis-data:/data \
  redis:7-alpine redis-server \
    --appendonly yes \
    --requirepass "YourSecurePassword"

docker exec -it redis redis-cli -a YourSecurePassword ping

Use Docker Compose for multi-node Sentinel or Cluster testing environments.

Build from Source (Latest Version) 

  wget https://download.redis.io/redis-stable.tar.gz
tar xzf redis-stable.tar.gz
cd redis-stable
make
sudo make install

redis-server --version

Useful when package managers lag behind the latest stable release.

Initial Configuration

Edit /etc/redis/redis.conf (or your platform equivalent):

  # Network — bind to localhost in dev; private IP in production
bind 127.0.0.1 ::1
port 6379
protected-mode yes

# Security (Redis 6+ ACL recommended over requirepass alone)
requirepass YourSecurePassword

# Memory limits
maxmemory 256mb
maxmemory-policy allkeys-lru

# Persistence (adjust per workload)
appendonly yes
appendfsync everysec

# Logging
loglevel notice
logfile /var/log/redis/redis-server.log

# Disable dangerous commands in production
rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command CONFIG ""

Restart after changes:

  sudo systemctl restart redis-server

ACL Setup (Redis 6+)

Prefer ACLs over a single shared password:

  redis-cli

127.0.0.1:6379> ACL SETUSER appuser on >AppSecurePass ~app:* +@read +@write -@dangerous
127.0.0.1:6379> ACL SETUSER admin on >AdminSecurePass ~* +@all
127.0.0.1:6379> ACL LIST

Application clients connect as appuser; operators use admin for maintenance.

Verification Checklist 

  # Connectivity
redis-cli ping
# PONG

# With auth
redis-cli -a YourSecurePassword ping

# Basic operations
redis-cli SET test:install "ok" EX 60
redis-cli GET test:install

# Server info
redis-cli INFO server
redis-cli INFO memory

systemd Service Management 

  sudo systemctl start redis-server
sudo systemctl stop redis-server
sudo systemctl restart redis-server
sudo systemctl status redis-server

# View logs
journalctl -u redis-server -f

Ensure Restart=always is set in the unit file for production auto-recovery.

Best Practices

  1. Never expose port 6379 to the public internet — use VPC private subnets or VPN
  2. Set maxmemory before going live — unbounded Redis consumes all available RAM
  3. Use TLS for connections crossing untrusted networks (Redis 6+)
  4. Run Redis on dedicated memory — avoid swapping (vm.overcommit_memory = 1 on Linux)
  5. Pin Redis version in production — test upgrades in staging first

Common Mistakes

Mistake Consequence
Default bind 0.0.0.0 without auth Open Redis on the internet — instant compromise
No maxmemory limit OOM kills the host or evicts unpredictably
Using FLUSHALL in production scripts Catastrophic data loss
Ignoring vm.overcommit_memory Background save failures, fork errors
Same Redis for dev and prod credentials Credential leaks in code repos

Troubleshooting

“Could not connect to Redis”:

  ss -tlnp | grep 6379          # Is Redis listening?
grep ^bind /etc/redis/redis.conf
sudo tail -f /var/log/redis/redis-server.log

Background save failed (fork error):

  # Linux: enable overcommit
sudo sysctl vm.overcommit_memory=1
echo 'vm.overcommit_memory = 1' | sudo tee -a /etc/sysctl.conf

Permission denied on data directory:

  sudo chown redis:redis /var/lib/redis
sudo chmod 750 /var/lib/redis

Performance Tips

  • Disable Transparent Huge Pages on Linux: echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
  • Place RDB/AOF files on fast local SSD — not network filesystems
  • Set tcp-backlog 511 and ensure OS somaxconn matches for high connection counts

Production Scenario

A fintech startup deployed Redis on three dedicated r6g.large instances (ARM, 16 GB RAM) in a private subnet. ACLs separated cache (app-cache user, read/write on cache:*) from session storage (app-session user). TLS terminated at an internal load balancer. Automated backups pushed RDB snapshots to S3 every hour. Zero public exposure — all access via application security groups only.

Proper installation and hardening on day one prevents the most common Redis security incidents — misconfigured instances scanned and exploited within minutes of going public.