Securing Redis on a VPS: Keep It Private and Bound Its Memory

Redis should normally be reachable only by trusted applications, with appropriate authentication and access controls. Do not expose it publicly just because a NAT mapping is available or because the assigned port is uncommon.

Inspect the listener

Check ss -lnt and Redis's effective configuration. A service intended only for a local application should not need a public mapping. Binding to loopback reduces network exposure, but you still need to consider other local users and application security.

Protected mode is useful, but it is not a complete substitute for a deliberate network design. Review ACLs and authentication for the installed Redis version. Avoid putting passwords in command lines, public repositories or support screenshots.

Decide whether data is disposable

Using Redis only as a cache differs from using it as a queue or primary data store. Persistence settings, eviction policy and backup needs follow from that choice. An eviction policy that is acceptable for cached pages may be unacceptable for queued business tasks.

Set a realistic memory budget

Configure and monitor memory limits with enough room for the OS, application and Redis overhead. Some operations and persistence activity can increase memory demand beyond the stored dataset. A guest-level out-of-memory event can terminate a critical process even when the disk is mostly empty.

For remote administration, consider a loopback-bound SSH tunnel instead of a public database port. Verify recovery from a restart with test data before relying on persistence.

See private SSH forwarding, memory and swap and backups.

Reference: Redis security documentation.