How to Install Redis on Ubuntu 26.04, 24.04 and 22.04

Fast caches, queue backends, rate limits, and session stores all benefit from memory-first reads instead of repeated trips to disk-backed storage. You can install Redis on Ubuntu to add that low-latency data layer for web applications, background workers, and other services that need quick key-value access.

Ubuntu 26.04, 24.04, and 22.04 already package Redis in the default repositories, while the official Redis repository currently offers a newer branch on Ubuntu 24.04 and 22.04. On Ubuntu 26.04, the default Ubuntu package is currently the supported APT path because Redis.io does not publish a native resolute repository yet.

Install Redis on Ubuntu

Ubuntu and Redis.io both install Redis through APT, but they target different priorities: distro-managed stability versus a newer upstream branch on supported LTS releases. The commands install redis-server with redis-tools, which provides redis-cli.

Method	Package Source	Branch	Updates	Best For
Ubuntu APT Repository	Ubuntu redis-server package	Ubuntu release default	Automatic through apt upgrade	Production servers that prioritize distro integration and long-term maintenance
Redis.io Repository	Redis APT documentation	Redis.io stable APT branch	Automatic through apt upgrade	Ubuntu 24.04 and 22.04 systems that need a newer Redis branch

Choose a Redis Package Source on Ubuntu

• Use Ubuntu’s default repository for the simplest production path, especially on Ubuntu 26.04 where Ubuntu already ships Redis 8.0.x and Redis.io does not yet publish a native resolute repository.
• Use the Redis.io repository on Ubuntu 24.04 or 22.04 when your application needs Redis 8.6.x instead of the Redis branch packaged with that LTS release.
• Stay with your LTS branch when Redis 6.0.x on Ubuntu 22.04, Redis 7.0.x on Ubuntu 24.04, or Redis 8.0.x on Ubuntu 26.04 already meets your application requirements.

Ubuntu also has a redis metapackage that pulls in the server and tools, but installing redis-server and redis-tools directly keeps the service package and CLI tools explicit.

Method 1: Install Redis via the Ubuntu APT Repository

Update Ubuntu Before Redis Installation

Refresh the package index before installing Redis so APT pulls the latest package set for your Ubuntu release.

sudo apt update && sudo apt upgrade

These commands use sudo for package-management tasks. If your account does not have sudo access yet, follow the guide on how to add a new user to sudoers on Ubuntu or run the commands as root.

Install Redis via APT Command

Ubuntu includes Redis in the default repository. Next, install the server package and command-line tools:

sudo apt install redis-server redis-tools

This command installs the redis-server package for the daemon and the redis-tools package that provides redis-cli and the related client utilities. Across Ubuntu 22.04, 24.04, and 26.04, the packaged redis-server.service unit already starts Redis with --supervised systemd --daemonize no, so there is no separate supervision edit to make after installation.

Verify Redis Installation

Confirm the installed package and the Ubuntu component that provides it:

apt-cache policy redis-server

Relevant output includes:

redis-server:
   Installed: 5:8.0.5-1
   Candidate: 5:8.0.5-1
   Version table:
 *** 5:8.0.5-1 500
            500 http://au.archive.ubuntu.com/ubuntu resolute/universe amd64 Packages
            100 /var/lib/dpkg/status

This confirms Redis comes from Ubuntu’s universe component. Ubuntu 24.04 currently installs Redis 7.0.15, and Ubuntu 22.04 installs Redis 6.0.16. If your host is minimal or uses a trimmed package-source setup and apt-cache policy shows Candidate: (none), first enable Universe on Ubuntu and refresh APT.

redis-cli --version

The client version should match the installed Redis branch:

redis-cli 8.0.5

The Ubuntu package enables and starts redis-server during installation. Check the live service state:

systemctl status redis-server --no-pager

Relevant output includes:

redis-server.service - Advanced key-value store
     Loaded: loaded (/usr/lib/systemd/system/redis-server.service; enabled; preset: enabled)
     Active: active (running)
     Status: "Ready to accept connections"

Together, these checks confirm Redis is installed correctly and the service is running under systemd.

Method 2: Install Redis via the Redis.io APT Repository on Ubuntu

The Redis.io APT repository currently publishes packages for Ubuntu 24.04 and 22.04. Ubuntu 26.04 does not have a native resolute repository yet, so stay with the default Ubuntu package on that release.

Update Ubuntu Before Redis.io Installation

Refresh package metadata before adding the third-party Redis repository:

sudo apt update && sudo apt upgrade

Install Redis.io Repository Prerequisites

Next, install packages needed for secure repository management:

sudo apt install ca-certificates curl gpg

These tools handle HTTPS access and GPG key management for the new package source. The curl command downloads the signing key, and gpg converts it into the keyring format APT expects.

Add Redis.io Repository

Import the Redis.io signing key and write a DEB822 source file for the repository:

. /etc/os-release
case "$VERSION_CODENAME" in
  noble|jammy)
    curl -fsSL https://packages.redis.io/gpg | sudo gpg --dearmor --yes -o /usr/share/keyrings/redis-archive-keyring.gpg
    sudo chmod 644 /usr/share/keyrings/redis-archive-keyring.gpg
    printf '%s\n' \
    "Types: deb" \
    "URIs: https://packages.redis.io/deb" \
    "Suites: $VERSION_CODENAME" \
    "Components: main" \
    "Architectures: $(dpkg --print-architecture)" \
    "Signed-By: /usr/share/keyrings/redis-archive-keyring.gpg" | sudo tee /etc/apt/sources.list.d/redis.sources > /dev/null
    ;;
  *)
    printf 'Redis.io does not currently publish packages for Ubuntu %s; use the Ubuntu APT repository method instead.\n' "$VERSION_CODENAME"
    ;;
esac

The shell reads /etc/os-release so $VERSION_CODENAME expands to your Ubuntu codename. The guard writes the source only on noble or jammy; on resolute, stop this method and use the Ubuntu repository package instead. dpkg --print-architecture adds the matching APT architecture so the DEB822 file stays portable across supported hosts.

Refresh the Redis.io Package Cache

Update APT and confirm it sees the new Redis source. Continue only if the previous command wrote /etc/apt/sources.list.d/redis.sources for Ubuntu 24.04 or 22.04.

sudo apt update

APT should finish without repository errors. The next source-priority check is the more stable proof that Ubuntu can see the Redis.io packages.

Install Redis from Redis.io Repository

Now install Redis server and command-line tools from the Redis.io repository. If Redis is already installed from Ubuntu’s default repository, this command upgrades to the Redis.io version:

sudo apt install redis-server redis-tools

Verify Redis.io Installation

Confirm the installed version comes from the Redis.io repository:

apt-cache policy redis-server

Relevant output includes:

redis-server:
   Installed: 6:8.6.3-1rl1~noble1
   Candidate: 6:8.6.3-1rl1~noble1
  Version table:
 *** 6:8.6.3-1rl1~noble1 500
        500 https://packages.redis.io/deb noble/main amd64 Packages
        100 /var/lib/dpkg/status
       5:7.0.15-1ubuntu0.24.04.4 500
            500 http://au.archive.ubuntu.com/ubuntu noble-updates/universe amd64 Packages
            500 http://security.ubuntu.com/ubuntu noble-security/universe amd64 Packages

This confirms APT now prefers the Redis.io packages over Ubuntu’s default universe build. On Ubuntu 22.04, the Redis.io candidate also moves to the Redis 8.6.x branch while Ubuntu’s own package remains on Redis 6.0.16.

systemctl status redis-server --no-pager

The Redis.io packages keep the same redis-server systemd unit, so the service stays enabled after the upgrade. Relevant output includes:

redis-server.service - Advanced key-value store
     Loaded: loaded (/usr/lib/systemd/system/redis-server.service; enabled; preset: enabled)
     Active: active (running)
     Status: "Ready to accept connections"

At this point, Redis should be actively listening on localhost at the default port 6379. Confirm the listener with ss:

ss -tln 'sport = :6379'

Relevant output includes:

State  Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0      511        127.0.0.1:6379      0.0.0.0:*
LISTEN 0      511            [::1]:6379         [::]:*

Test Redis Connections with redis-cli

Test the Redis service with a direct redis-cli ping:

redis-cli ping

A healthy local service responds with:

PONG

The PONG response confirms Redis is accepting local commands. Redis is now operational and ready for memory tuning, network restrictions, authentication, and firewall changes.

Configure Redis Core Settings on Ubuntu

Redis configuration controls memory usage, network access, and authentication through settings in /etc/redis/redis.conf. These are the core changes most servers make first: memory limits, bind addresses, and authentication.

Open the Redis Configuration File

First, open the Redis configuration file to adjust memory, network, and authentication settings:

sudo nano /etc/redis/redis.conf

Set Redis Memory Limits

Redis operates in-memory by default without memory limits, risking system instability if data grows unchecked. Therefore, set explicit memory limits and eviction policies to control resource usage. Add these lines at the end of the configuration file:

maxmemory 500mb
maxmemory-policy allkeys-lru

This configuration caps Redis memory usage at 500 MB and applies the Least Recently Used (LRU) eviction policy when the limit is reached. The allkeys-lru policy removes the least recently accessed keys from the entire keyspace, making it suitable for general caching workloads. If you need to preserve persistent keys with no expiration, tune the policy using the key-expiration guidance later in this section. For production systems, allocate 60-70% of available RAM to leave headroom for operating system processes and Redis memory overhead.

Configure Redis Network Binding

Redis defaults to binding only the localhost interface (127.0.0.1), restricting access to local processes. However, remote access requires changing the bind directive to accept connections from specific IP addresses, subnets, or all interfaces. Locate the bind directive in the configuration file (typically around line 69).

Binding Redis to external interfaces exposes it to network access. Always pair that change with ACLs, restrictive firewall rules, and either TLS or an SSH tunnel after you install SSH on Ubuntu.

Option 1: Listen on all network interfaces

To allow all interfaces, comment out the bind directive to accept connections on all interfaces:

# bind 127.0.0.1 ::1

This configuration permits connections from any interface. However, use this only in development environments or when combined with strict firewall rules.

Option 2: Bind to specific IP addresses

Alternatively, specify one or more IP addresses to restrict which interfaces accept connections. Replace the bind directive with your server’s IP address:

bind 192.168.1.100 127.0.0.1

This example binds to the private network address 192.168.1.100 and maintains localhost access. Additionally, multiple space-separated addresses are supported. Choose addresses matching your network topology, such as private RFC1918 ranges for internal networks, and use public IPs only when paired with authentication and firewall protection.

Enable Password Authentication with ACLs

Redis 6.0+ uses Access Control Lists (ACLs) for authentication, replacing the legacy requirepass directive. Consequently, ACLs provide granular control over user permissions, allowing you to create multiple users with specific command and keyspace restrictions. First, generate a strong password:

openssl rand -base64 32

Copy the generated password into a password manager. Then open the Redis configuration file and scroll to the ACL section (typically around line 1000). Disable the default user and create a new user with your password:

# Disable the default user for security
user default off

# Create new user with full permissions
user redisuser on >YourGeneratedPasswordHere ~* &* +@all

This ACL rule creates redisuser with full permissions: on enables the user, >password sets the password, ~* grants access to all keys, &* allows all Pub/Sub channels, and +@all permits all commands. For production systems, restrict permissions using categories like +@read, +@write, and -@dangerous to limit command access.

After enabling password authentication, clients must authenticate. Use the --user and --askpass flags so the password is not placed on the command line:

redis-cli --user redisuser --askpass PING

Enter your password when prompted. Successful authentication returns:

PONG

The PONG response confirms successful authentication. If you enable ACLs, add --user redisuser --askpass to later redis-cli examples that need to connect to the protected server.

Older Redis installations may use the legacy requirepass directive for simple password authentication. While functional, requirepass provides only single-user authentication without permission controls. Redis 6.0+ strongly recommends ACLs for production deployments, offering per-user command restrictions and improved security through the principle of least privilege.

Apply Redis Configuration Changes

Save the configuration file (press Ctrl + O, then Enter) and exit nano (Ctrl + X). Afterwards, restart Redis to load the new settings:

sudo systemctl restart redis-server

Verify Redis restarted successfully without configuration errors:

systemctl status redis-server --no-pager

redis-server.service - Advanced key-value store
     Loaded: loaded (/usr/lib/systemd/system/redis-server.service; enabled; preset: enabled)
     Active: active (running)
     Status: "Ready to accept connections"

Check for “active (running)” status. Configuration errors appear in the service logs, accessible with journalctl -u redis-server -n 50.

Configure Firewall Rules for Redis on Ubuntu

Redis listens on TCP port 6379 by default. If you configured Redis to accept network connections beyond localhost, adjust your firewall rules to permit access from trusted sources while blocking unauthorized attempts. If you still need the firewall itself set up, follow the steps in install and configure UFW on Ubuntu before you add Redis-specific rules.

Ensure UFW Is Ready for Redis

First, make sure UFW is installed on your system:

sudo apt install ufw

Before enabling UFW, allow SSH to prevent locking yourself out of remote sessions:

sudo ufw allow OpenSSH

Next, enable UFW without the interactive confirmation prompt:

sudo ufw --force enable

Relevant output confirms the firewall is active:

Firewall is active and enabled on system startup

Add Redis Firewall Rules

Now, restrict Redis access to specific IP addresses or subnets based on your network architecture. Never expose Redis port 6379 to the public internet without additional security layers like VPNs or TLS proxies.

Option 1: Allow access from a specific IP address

For example, grant access to a single application server or bastion host:

sudo ufw allow proto tcp from 192.168.1.50 to any port 6379

UFW confirms the rule addition:

Rule added

Replace 192.168.1.50 with your application server’s IP address. Consequently, this rule permits only the specified host to connect to Redis while blocking all other addresses.

Option 2: Allow access from a subnet

For Redis clusters or multiple application servers within a trusted network segment, allow an entire subnet:

sudo ufw allow proto tcp from 192.168.1.0/24 to any port 6379

This permits any host in the 192.168.1.0/24 range to connect. Use subnet rules only for secure internal networks where all hosts are trusted, because a compromised machine within the subnet gains Redis access.

Verify Redis Firewall Rules

Test Redis connectivity from an allowed client machine to confirm firewall rules work as expected:

redis-cli -h 192.168.1.100 ping

Replace 192.168.1.100 with your Redis server’s IP address. A successful connection returns:

PONG

If authentication is enabled, use --askpass instead of placing the password in the command:

redis-cli -h 192.168.1.100 --user redisuser --askpass ping

Connection timeouts or “Connection refused” errors indicate firewall blocking or incorrect bind configuration.

Configure Advanced Redis Options on Ubuntu

Beyond basic memory limits and authentication, Redis offers advanced configuration options for performance tuning and operational monitoring. These settings control key eviction behavior, connection management, query performance logging, event notifications, and debug output levels.

Configure Redis Key Expiration Policy

The maxmemory-policy setting determines which keys Redis evicts when memory limits are reached. If you run general caches, keep the earlier allkeys-lru value. When your dataset mixes cached items with critical persistent records, switch the directive to volatile-lru, which removes the least recently used keys only among those with expiration times set. Locate and modify this setting in /etc/redis/redis.conf:

maxmemory-policy volatile-lru

The maxmemory-samples setting controls eviction accuracy by determining how many keys Redis samples when selecting candidates for removal. Furthermore, higher values improve eviction quality at the cost of CPU usage:

maxmemory-samples 5

The default value of 5 balances accuracy and performance for most workloads. Alternatively, increase to 10 for applications requiring precise LRU approximation, or decrease to 3 for high-throughput environments prioritizing speed over eviction precision.

Configure Redis TCP Keepalive

TCP keepalive probes detect and close idle connections, freeing system resources. Accordingly, set the tcp-keepalive interval (in seconds) to enable periodic connection checks:

tcp-keepalive 300

This configuration sends keepalive probes every 300 seconds (5 minutes). Lower values detect dead connections faster but increase network overhead, while higher values reduce overhead at the cost of delayed detection. Adjust based on your network reliability and connection patterns.

Configure Redis Slow Log Monitoring

Slow query logging identifies performance bottlenecks by recording commands exceeding a specified execution time. Therefore, configure the threshold (in microseconds) and maximum log entries:

slowlog-log-slower-than 10000
slowlog-max-len 128

This logs commands taking longer than 10,000 microseconds (10 milliseconds) and retains the 128 most recent slow queries. Lower thresholds catch more queries but generate more log entries, while higher thresholds focus on severe performance issues. To inspect them, review slow logs with the SLOWLOG GET command in redis-cli:

redis-cli SLOWLOG GET 5

Example output showing slow query entries:

1) 1) (integer) 14
   2) (integer) 1731758423
   3) (integer) 12450
   4) 1) "KEYS"
      2) "user:*"
   5) "127.0.0.1:52134"
   6) ""
2) 1) (integer) 13
   2) (integer) 1731758401
   3) (integer) 15230
   4) 1) "ZRANGE"
      2) "leaderboard"
      3) "0"
      4) "100"
   5) "127.0.0.1:52134"
   6) ""

Each entry shows the unique ID, timestamp, execution time in microseconds, command with arguments, client address, and client name. As a result, this helps identify expensive operations like KEYS * patterns or large range queries that should be optimized or avoided.

Enable Redis Event Notifications

Keyspace notifications publish events when keys expire, get evicted, or undergo specific operations. Enable notifications by configuring the notify-keyspace-events setting with event type flags:

notify-keyspace-events ExA

The Ex flags enable notifications for expired keys (x) and evicted keys (e), while A is an alias for all event types. Applications can subscribe to these events using PSUBSCRIBE to track key lifecycle changes, implement cache invalidation patterns, or monitor expiration behavior. Test event notifications by subscribing in one terminal:

redis-cli PSUBSCRIBE '__keyevent@0__:expired'

In another terminal, set a key with a short expiration:

redis-cli SETEX testkey 5 "temporary value"

After 5 seconds, the first terminal displays the expiration event:

1) "pmessage"
2) "__keyevent@0__:expired"
3) "__keyevent@0__:expired"
4) "testkey"

Notifications add minimal overhead but generate significant traffic in high-throughput environments with frequent expirations or evictions.

Adjust Redis Logging Level

Redis logging verbosity controls how much information appears in logs. Set the loglevel directive to balance debugging needs against log volume:

loglevel notice

The notice level (default) logs important messages without excessive detail. Use debug for troubleshooting with full command logging, verbose for detailed operational information, or warning to log only critical errors. Production systems typically use notice or warning to minimize log storage and parsing overhead.

Enable Redis Unix Sockets for Local Connections

Applications running on the same server as Redis should use Unix domain sockets instead of TCP connections. Unix sockets bypass the network stack entirely, providing faster performance and better security through filesystem permissions. Enable Unix socket support in /etc/redis/redis.conf:

unixsocket /var/run/redis/redis.sock
unixsocketperm 770

This creates a socket at /var/run/redis/redis.sock with 770 permissions, allowing the Redis user and group to access it while blocking others. After restarting Redis, connect using the socket file instead of the TCP port:

redis-cli -s /var/run/redis/redis.sock ping

A working Unix socket returns:

PONG

Notably, Unix sockets eliminate network-based attacks since the socket is only accessible via the filesystem, not the network.

Configure Redis Idle Connection Timeout

Idle client connections consume server resources unnecessarily. Consequently, configure the timeout directive to automatically close connections that remain idle beyond a specified duration:

timeout 300

This closes connections idle for 300 seconds (5 minutes), freeing memory and file descriptors. Alternatively, set timeout 0 to disable automatic closure, though this allows idle connections to persist indefinitely. Production environments should use timeouts to prevent resource exhaustion from abandoned connections.

Configure Redis Data Persistence on Ubuntu

Redis operates primarily in memory but offers two persistence mechanisms to survive restarts and crashes: RDB snapshots and Append-Only File (AOF). Understanding both options helps you balance performance against data durability requirements.

Configure Redis RDB Snapshots (Point-in-Time Backups)

RDB creates compact point-in-time snapshots of your dataset at specified intervals. Redis forks a child process to write the snapshot asynchronously, minimizing impact on the main server. Configure RDB snapshots in /etc/redis/redis.conf using save directives:

save 900 1
save 300 10
save 60 10000

These default settings balance write frequency against disk I/O overhead. The save 900 1 line snapshots after one change within 15 minutes, save 300 10 does so after ten changes within five minutes, and save 60 10000 captures rapid bursts of writes. RDB files are compact and fast to load, making them ideal for backups and disaster recovery. However, RDB snapshots can lose data written between snapshots if Redis crashes unexpectedly. For critical data requiring maximum durability, combine RDB with AOF.

By default, RDB snapshots write to /var/lib/redis/dump.rdb. If you need to customize the destination, configure the filename and location with:

dbfilename dump.rdb
dir /var/lib/redis

After saving the file and restarting Redis, trigger a manual save and check for a non-empty snapshot file:

redis-cli SAVE
sudo test -s /var/lib/redis/dump.rdb && echo dump.rdb-present

Expected output confirms Redis accepted the snapshot request and wrote the RDB file:

OK
dump.rdb-present

Additionally, check persistence status in Redis:

redis-cli INFO PERSISTENCE

Example output showing RDB configuration:

# Persistence
rdb_bgsave_in_progress:0
rdb_last_bgsave_status:ok

Configure Redis AOF (Append-Only File) Persistence

AOF logs every write operation to a file, providing superior data durability compared to RDB snapshots. To enable it, configure AOF persistence:

appendonly yes
appendfilename "appendonly.aof"

AOF offers three synchronization policies controlling when writes flush to disk. The appendfsync directive balances durability against performance:

appendfsync everysec

Set the directive to everysec for the recommended balance, switch to always to sync after every write when you can afford the steep performance hit, or choose no to let the kernel flush data opportunistically for maximum throughput and higher risk of loss.

AOF files grow continuously as Redis logs operations. Therefore, enable automatic AOF rewriting to compact the file by replaying operations and removing redundancy:

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

These settings trigger rewrites when the AOF file doubles in size and exceeds 64MB. Adjust thresholds based on write patterns and disk capacity to prevent excessive rewrite frequency.

After enabling rewriting and restarting Redis, verify AOF persistence is active. Redis 7.0 and newer store multipart AOF files under /var/lib/redis/appendonlydir/, while older Redis 6.0 installations may use a single /var/lib/redis/appendonly.aof file.

sudo find /var/lib/redis -maxdepth 2 \( -name 'appendonly.aof*' -o -name '*.aof' \) -print

Relevant output on Redis 7.0 and newer includes the multipart AOF files:

/var/lib/redis/appendonlydir/appendonly.aof.manifest
/var/lib/redis/appendonlydir/appendonly.aof.1.base.rdb
/var/lib/redis/appendonlydir/appendonly.aof.1.incr.aof

Then check AOF status in Redis:

redis-cli INFO PERSISTENCE | grep aof

Example output confirming AOF is enabled:

aof_enabled:1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok

Production systems requiring maximum durability should enable both RDB and AOF persistence. RDB provides fast restarts and efficient backups, while AOF guarantees minimal data loss during failures. Enable both by configuring save directives alongside appendonly yes. Redis 7.0+ supports AOF with RDB preamble format, combining the best of both approaches for optimal recovery performance.

After configuring the desired options, save your changes and restart Redis:

sudo systemctl restart redis-server

Enable Redis TLS/SSL Encryption on Ubuntu

Redis 6.0+ supports TLS encryption for client connections, protecting data in transit from eavesdropping and man-in-the-middle attacks. Consequently, TLS is critical when Redis serves remote clients over untrusted networks, though local connections via Unix sockets or localhost typically don’t require encryption overhead.

First, create a small certificate authority (CA) and server certificate for testing. For production, replace the generated server certificate with one issued by your internal or public CA:

sudo mkdir -p /etc/redis/tls
cd /etc/redis/tls
sudo openssl req -x509 -newkey rsa:4096 -keyout redis-ca.key -out redis-ca.crt -days 365 -nodes -subj "/CN=redis-ca"
sudo openssl req -newkey rsa:4096 -keyout redis-server.key -out redis-server.csr -nodes -subj "/CN=redis.example.com"
sudo openssl x509 -req -in redis-server.csr -CA redis-ca.crt -CAkey redis-ca.key -CAcreateserial -out redis-server.crt -days 365

Keep the CA private key restricted to root for signing only. Then, grant Redis access to the server key and public certificates:

sudo chown redis:redis /etc/redis/tls/redis-server.key /etc/redis/tls/redis-server.crt /etc/redis/tls/redis-ca.crt
sudo chmod 640 /etc/redis/tls/redis-server.key
sudo chmod 644 /etc/redis/tls/redis-server.crt /etc/redis/tls/redis-ca.crt
sudo chmod 600 /etc/redis/tls/redis-ca.key

Now, configure Redis to use TLS by editing /etc/redis/redis.conf and enabling TLS directives:

tls-port 6380
port 0
tls-cert-file /etc/redis/tls/redis-server.crt
tls-key-file /etc/redis/tls/redis-server.key
tls-ca-cert-file /etc/redis/tls/redis-ca.crt

This enables TLS on port 6380 and disables the unencrypted port 6379 by setting port 0. The tls-ca-cert-file directive points Redis at the CA that signed your server certificate. For mutual TLS (mTLS) requiring client certificates, add tls-auth-clients yes and distribute client certificates signed by the same CA.

Restart Redis and verify TLS listens on port 6380:

sudo systemctl restart redis-server
ss -tln 'sport = :6380'

The output confirms Redis is listening on the TLS port:

State  Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0      511        127.0.0.1:6380       0.0.0.0:*

Connect to the TLS-enabled server using redis-cli with TLS options:

redis-cli --tls --cacert /etc/redis/tls/redis-ca.crt -p 6380 PING

If mTLS is enabled, add --cert and --key flags with a client certificate signed by your CA. A successful TLS connection returns:

PONG

The PONG response over port 6380 confirms TLS encryption is working properly. If using UFW, update firewall rules to allow the TLS port:

sudo ufw allow 6380/tcp comment 'Redis TLS'

TLS encryption adds computational overhead due to encryption and decryption operations. The performance impact varies depending on your workload, CPU capabilities, and connection patterns, so benchmark your specific use case with TLS enabled before deploying to production. For maximum security with remote access, combine TLS encryption with VPN or an SSH tunnel after you install SSH on Ubuntu. Applications running locally should use Unix sockets instead of TLS for better performance without sacrificing local security.

Troubleshoot Redis Issues on Ubuntu

Fix Redis Service Startup Failures

If Redis fails to start, check the service logs for specific error messages:

sudo journalctl -u redis-server -n 50 --no-pager

Common causes include configuration syntax errors, permission issues on the data directory, or port conflicts. The service log usually names the rejected directive or path that prevented startup.

Fix Redis Connection Refused Errors

If you receive “Connection refused” when connecting to Redis, verify the service is running and listening on the expected address:

ss -tln 'sport = :6379'

Also, check if firewall rules are blocking the connection:

sudo ufw status numbered

Finally, verify the bind address in /etc/redis/redis.conf matches your connection target. If Redis binds only to 127.0.0.1, remote connections will fail.

Fix Redis Authentication Errors

If you configured ACL users and receive “NOAUTH Authentication required” or “WRONGPASS invalid username-password pair”, verify your credentials without placing the password in the process list:

redis-cli --user your_username --askpass PING

To check configured users, authenticate with an administrative ACL user, then list ACL entries:

redis-cli --user adminuser --askpass ACL LIST

Fix Redis Memory Limit Issues

When Redis reaches its memory limit, behavior depends on your maxmemory-policy setting. Check current memory usage:

redis-cli INFO memory | grep -E 'used_memory|maxmemory'

If Redis is evicting keys unexpectedly or refusing writes, consider increasing maxmemory or adjusting the eviction policy in /etc/redis/redis.conf.

Remove Redis from Ubuntu

If you need to remove Redis from your system, start by purging the packages and then remove the optional Redis.io repository only if you added it on Ubuntu 24.04 or 22.04. Back up any data under /var/lib/redis before purging a server that has stored real application data.

Uninstall Redis Packages

Stop the service and purge the Redis packages. Including redis covers systems where the metapackage was installed instead of the explicit server and tools packages:

sudo systemctl stop redis-server
sudo apt purge redis redis-server redis-tools

The purge removes package-managed configuration files and may remove Redis-owned runtime paths. Review any remaining Redis data, logs, or custom paths before deleting them manually.

Review custom backup directories, non-default Redis data paths, and application-owned caches before deleting them. Redis data can represent rebuildable cache entries, queued jobs, or important application state depending on how your services use it.

Confirm the packages are no longer installed:

dpkg -l redis redis-server redis-tools | grep '^ii'

No output means the packages are no longer installed. After that, preview any no-longer-needed dependencies before removing them:

sudo apt autoremove --dry-run

If APT lists only packages you no longer need, run the cleanup interactively so you can confirm the removal list:

sudo apt autoremove

Remove Redis.io Repository (If Added)

If you added the Redis.io repository on Ubuntu 24.04 or 22.04, remove the source file and signing key before refreshing APT:

sudo rm -f /etc/apt/sources.list.d/redis.sources
sudo rm -f /usr/share/keyrings/redis-archive-keyring.gpg
sudo apt update

Use apt-cache policy to confirm Redis is no longer installed and, if you removed the Redis.io repository, that APT has fallen back to Ubuntu’s own package metadata:

apt-cache policy redis-server

Relevant output includes:

redis-server:
  Installed: (none)
  Candidate: 5:7.0.15-1ubuntu0.24.04.4
  Version table:
     5:7.0.15-1ubuntu0.24.04.4 500
        500 http://au.archive.ubuntu.com/ubuntu noble-updates/universe amd64 Packages
        500 http://security.ubuntu.com/ubuntu noble-security/universe amd64 Packages

Installed: (none) confirms the package is gone. On Ubuntu 24.04 and 22.04, the candidate should revert to Ubuntu’s universe package once the Redis.io source file has been removed.

Conclusion

Redis on Ubuntu is now running from the package source that fits your release, whether that is Ubuntu’s default archive or the newer Redis.io branch on 24.04 and 22.04. If you plan to expose it beyond localhost, lock it down with the steps in install and configure UFW on Ubuntu and use an SSH tunnel after you install SSH on Ubuntu instead of leaving port 6379 broadly reachable.