Redis is a high-performance, in-memory key/value store that’s often used for caching, session storage, message brokering, and more. Because it keeps data in memory (with optional persistence), it offers microsecond latency and high throughput. That said, Redis was originally developed to run in trusted environments, so exposing it directly to the internet carries risk if not properly secured.
While DigitalOcean offers a managed Redis (now often called Managed Caching) product, hosting your own gives you full control over versioning, configuration, and operational flexibility. That comes at the cost of needing to maintain uptime, backups, scaling, and security yourself.
In what follows, I’ll assume you’re running Ubuntu (e.g. 22.04 LTS), but the pattern is similar on Debian or other Linux distros. I’ll also show you how to install the most recent Redis versions (e.g. 7.x or 8.x) using the official Redis packages, or compile from source if needed. (Redis publishes official packages — you should prefer that when available)
Step 1: Provision a DigitalOcean Droplet
- Log into your DigitalOcean dashboard and create a new Droplet.
- Choose an image (Ubuntu 22.04 LTS is safe).
- Select a size (at least 1 GB RAM is good for light traffic; 2 GB or more for moderate use).
- Pick a region close to your app servers.
- Add your SSH public key (recommended) so that you can securely log in without passwords.
- Wait until the droplet is ready, then note its public IP (and internal/private IP if configured).
- SSH in using your non-root user (or root, but non-root with sudo is safer):
ssh your_user@your_droplet_ip
- (Optional but recommended) run initial server setup:
- Update packages
sudo apt update && sudo apt upgrade -y
- Create a non-root user if not already
sudo adduser redisadmin sudo usermod -aG sudo redisadmin
- Enable basic firewall to allow SSH only initially (we’ll open Redis later)
- Update packages
At this point, your droplet is ready to host Redis.
Step 2: Install Redis (official/repository method)
To ensure you can get updates, use the official Redis repository rather than just apt install
from the default Ubuntu repo (which may lag).
Install prerequisites and add the Redis repository:
# Install prerequisites
sudo apt-get install -y lsb-release curl gpg
# Import the Redis GPG key
curl -fsSL https://packages.redis.io/gpg | \
sudo gpg --dearmor -o /usr/share/keyrings/redis-archive-keyring.gpg
# Set correct permissions
sudo chmod 644 /usr/share/keyrings/redis-archive-keyring.gpg
# Add the Redis APT repository
echo "deb [signed-by=/usr/share/keyrings/redis-archive-keyring.gpg] \
https://packages.redis.io/deb $(lsb_release -cs) main" | \
sudo tee /etc/apt/sources.list.d/redis.list
# Update package index
sudo apt-get update
Install Redis: sudo apt-get install redis
After installation, Redis should start automatically.
Enable Redis to start at boot (if not already):
sudo systemctl enable redis-server
sudo systemctl start redis-server
Verify it runs: sudo systemctl status redis-server redis-cli ping
You should see “PONG” if the server is responsive.
(Alternate) Step 2b: Compile Redis from source
If you want full control (for example, enabling TLS or custom patches), you can compile Redis yourself:
- Install build dependencies (for Ubuntu):
sudo apt-get install -y build-essential tcl libssl-dev
- Download and extract:
wget https://download.redis.io/redis-stable.tar.gz tar -xzvf redis-stable.tar.gz cd redis-stable
- Build with optional TLS support:
make BUILD_TLS=yes make test sudo make install
This will installredis-server
,redis-cli
, and other tools under/usr/local/bin
by default. - (Optional) Write a systemd service file so that Redis is supervised. You can adapt existing templates or use the one from the official docs.
Compiling ensures you can tailor features, but it requires you to handle upgrades yourself.
Step 3: Basic Security Hardening
Because Redis trusts clients heavily, you must harden its configuration before exposing it to your app.
Bind address / network interface
By default, Redis may listen on all interfaces (0.0.0.0
). You should restrict it:
- In
/etc/redis/redis.conf
(or appropriate config file), ensure:bind 127.0.0.1 ::1 protected-mode yes
This causes Redis to accept only local connections by default. If your application server is separate, you might bind to your droplet’s private (VPC) IP instead of0.0.0.0
. - Restart Redis after changes:
sudo systemctl restart redis-server
Require authentication (password)
Uncomment and set a strong password:
In /etc/redis/redis.conf
:
# requirepass foobared
requirepass <your_strong_password_here>
Generate a strong password (for example):
openssl rand 60 | openssl base64 -A
Then restart Redis. Clients will now need to issue AUTH your_password
before performing commands.
Rename or disable dangerous commands
Redis allows you to rename or neutralize dangerous commands:
In the config:
rename-command FLUSHDB ""
rename-command FLUSHALL ""
rename-command DEBUG ""
# rename CONFIG to something else
rename-command CONFIG ASC12_CONFIG
Be cautious: renaming commands that occur in persistence or AOF can break replication or replay if not done consistently.
Firewall / UFW / network rules
Even with Redis properly configured, the strongest security is to prevent unauthorized access at the network level.
- Enable UFW and allow SSH first:
sudo ufw allow ssh sudo ufw enable
- If your application server runs elsewhere, allow only that IP (or subnet) to connect to Redis port 6379 (or your custom port):
sudo ufw allow from your_app_server_ip to any port 6379
- Deny all other incoming connections by default. Use
sudo ufw default deny incoming
. - If you prefer, you can also use DigitalOcean Cloud Firewalls (applied at the droplet level) for an extra layer.
Note: UFW and Docker can conflict because both manage iptables. If you run Docker on the same server you may need to adjust Docker’s iptables behavior.
Step 4: Connect your application to Redis
Once Redis is secured and listening, you need to connect your app code.
- If Redis is local (on same droplet or via private network) with no TLS, you might do:
host = "127.0.0.1" port = 6379 password = "your_password"
Clients typically allow a URI such as:redis://:your_password@127.0.0.1:6379/0
- If your application runs elsewhere, ensure it can reach the Redis server (via private IP or VPN). You may use TLS or SSH tunnel for encryption.
- Test via
redis-cli
from your application server (if accessible):redis-cli -h droplet_ip -a your_password ping
It should respond withPONG
. - In programming languages, you’ll set these same connection parameters. For example, in Python using
redis-py
:import redis r = redis.Redis(host='droplet_ip', port=6379, password='your_password', db=0) r.ping() # returns True if connection is live
Step 5: Persistence, backups, monitoring & scaling
Running Redis in production demands attention to durability, monitoring, and planning for growth.
Persistence settings (RDB / AOF)
Redis supports two primary persistence modes:
- RDB snapshots: periodic snapshotting of the dataset.
- AOF (Append-Only File): logs all write operations, more durable but larger logs.
In /etc/redis/redis.conf
, adjust settings like:
save 900 1 # snapshot every 900 sec if ≥1 key changed
save 300 10
save 60 10000
appendonly yes
You’ll need to choose tradeoffs between performance, durability, and disk usage.
Backups
Regularly back up the AOF or RDB file (e.g. /var/lib/redis/dump.rdb
or appendonly.aof) to an offsite store (like DigitalOcean Spaces).
You may script daily copies and rotate older backups.
Monitoring
- Use
redis-cli INFO
to see memory, clients, persistence stats. - Use tools like RedisInsight, Prometheus exporters, or
redis_exporter
to collect metrics. - Track memory usage, evictions, client counts, etc.
Scaling / high availability
If you need HA or scalability:
- Use Redis replication: one primary, one or more replicas.
- Promote a replica to primary if the master fails.
- Consider Redis Sentinel for automated failover.
- For truly large scale, sharding and clustering may be considered (Redis cluster mode), but that adds complexity.
Common pitfalls & recommendations
- Don’t expose Redis on
0.0.0.0
without restrictions. Attackers will probe port 6379. - Use strong passwords. Redis can process many auth attempts per second, so weak ones are brute-forced easily.
- Be careful renaming commands after enabling AOF or replication. Inconsistent renames across nodes can break replication.
- Monitor memory usage. Redis may evict keys or crash if memory is exhausted.
- Be cautious with persistence. AOF gives more durability but can slow writes.
- Test failover (if you use replication). Practice switching primaries safely.
- Keep software updated. Use official Redis repo so you can receive patches.