Install Redis from Distro Packages, Bind Localhost

A Redis install that answers on the public address of a VPS is not a cache. It is an open key-value store sitting on the internet, waiting for the next scanner that knows port 6379. The safe baseline is boring on purpose: install the distribution package, bind the daemon to localhost, restart, and prove from the public IP that nothing replies. Do that before you store a session, a job queue, or a single cached row.

Install the distribution package, not a random tarball

Distribution packages track the rest of the operating system. They ship a systemd unit, a redis user, a data directory with the right owner, and a config file under /etc. Unofficial install scripts skip those pieces. You then spend an evening discovering that a reboot started a second binary against an empty data dir, or that the process is still running as root.

On Ubuntu 24.04 or Debian 12 the package is redis-server and the unit is redis-server.service.

sudo apt-get update
sudo apt-get install -y redis-server
sudo systemctl enable --now redis-server
redis-cli ping

A PONG reply means the server answered on the local socket or on 127.0.0.1. It does not mean the public interface is closed. That check comes after bind.

On Rocky Linux 9 or AlmaLinux 9 the package name is redis and the unit is redis.service. Enable the module or extra repository your distro documents, then install and start.

sudo dnf install -y redis
sudo systemctl enable --now redis
redis-cli ping
systemctl cat redis

systemctl cat is the habit that saves you later. It prints the unit file systemd actually loaded, including the ExecStart line and the path to redis.conf. Debian-family systems use /etc/redis/redis.conf. RHEL-family systems use /etc/redis.conf. Edit the file the unit names, not the one a blog post assumed.

Bind 127.0.0.1 and leave protected-mode on

Two settings keep Redis private when the application shares the host. bind 127.0.0.1 is the one that matters. protected-mode is a second gate for the case where bind is wrong and no password is set: Redis then refuses remote commands instead of serving them. Do not treat protected-mode as a substitute for bind.

# /etc/redis/redis.conf on Debian and Ubuntu
bind 127.0.0.1
protected-mode yes
port 6379
supervised systemd

Commenting out bind, or setting bind 0.0.0.0, publishes Redis on every address including the one the world can reach. That is the most common production mistake on a small VPS. After the edit, restart and look at the listen table.

sudo systemctl restart redis-server
ss -lntp | grep 6379
redis-cli -h 127.0.0.1 ping

ss must show 127.0.0.1:6379 or a Unix socket. If you see 0.0.0.0:6379 or *:6379, stop. The instance is listening on every interface. Fix bind before you write a single key.

Then target the public address of the VPS, from the box itself or from a second machine. The connection must fail.

redis-cli -h 203.0.113.10 ping
# Connection refused or a timeout. Never PONG.

Replace 203.0.113.10 with the real public IP. A PONG here means the baseline failed. Take the service down, correct bind, and retest. Unix sockets are even tighter if the application can use them: set unixsocket /run/redis/redis.sock and unixsocketperm 660, then point the app at that path and leave TCP bound only to loopback.

Keep a host firewall in front of bind

Binding to localhost is the application-level control. A host firewall is the network-level one. They answer different failures: a future config edit that comments out bind, a container publish of 6379, or a second process that binds the port by accident.

On Ubuntu with ufw, deny the port even though nothing should be listening publicly.

sudo ufw deny 6379/tcp
sudo ufw status numbered
ss -lntp | grep 6379

On firewalld, keep 6379 out of the public zone. Lucknow DC01 already sits behind L3/L4 filtering on the Netbay edge, but that filtering is not a reason to skip bind or the host firewall. Scanners still hit the public IP. Redis should never be the process that answers them.

If you later need Redis on a private network between two VPS nodes, bind the private address only, require a password or ACL, and still leave 6379 closed on the public interface. That is a later post. Today the rule is simpler: application and Redis share a host, so Redis listens on 127.0.0.1 and nowhere else.

Takeaway

Install Redis from the distro, bind 127.0.0.1, restart, and prove the public IP refuses 6379. That is the whole baseline. You can spin up an Ubuntu 24.04 instance on Netbay in under 60 seconds and follow along — netbayhosts.in.