Why self-host Redis on a VPS
Redis lives in memory: its performance depends directly on RAM and network latency. Managed offerings charge a high price for each GB of RAM and impose connection caps. On a VPS, you size the RAM according to your real needs, you freely configure maxmemory and the eviction policy (allkeys-lru, volatile-ttl...), and you enable RDB and/or AOF persistence depending on your tolerance for data loss. For an application cache, a job broker (Sidekiq, BullMQ, Celery), or a session store, a Redis placed right next to your application on the same private network eliminates inter-datacenter latency and drastically reduces cost.
The concrete benefits of a self-hosted Redis
- Sub-millisecond latency if Redis runs on the same VPS or the same private network as your app.
- Control of
maxmemoryand the eviction policy according to your cache or job-queue use case. - Persistence of your choice: RDB (snapshots), AOF (journal), or both for durability.
- RAM cost without overcharging: you pay the VPS plan, not premium memory by the GB.
- Free modules: RediSearch, RedisJSON, RedisBloom as needed.
- No arbitrary cap on the number of simultaneous client connections.
Hardware and software prerequisites
Since Redis is in-memory, it's the RAM that matters, not the CPU. For a modest cache or a session store, 1 vCPU and 1 to 2 GB of RAM are enough. If Redis serves as a broker for thousands of queued jobs or stores multi-GB in-memory datasets, size the RAM to at least twice your target maxmemory to absorb the copy-on-write during RDB snapshots. On the software side: Ubuntu 22.04/24.04 LTS, Docker and Compose v2, a persistent volume for AOF/RDB if you enable persistence, and the vm.overcommit_memory=1 setting on the host to avoid fork failures during backups.
Deploying Redis with Docker in production
Prepare the host
Install Docker, then set vm.overcommit_memory=1 via sysctl to make snapshots reliable, and disable Transparent Huge Pages. Close port 6379 to the outside: a Redis exposed without a password is a classic target for cryptominers.
Write the docker-compose.yml
Declare a redis:7-alpine service with a custom command pointing to a redis.conf mounted as read-only. Enable requirepass, set maxmemory and maxmemory-policy, and mount a volume for /data if you want persistence.
Configure security
In redis.conf, set a strong password via requirepass, rename or disable dangerous commands (FLUSHALL, CONFIG) with rename-command, and restrict listening to the internal network. For remote access, enable Redis's native TLS (tls-port) or go through a tunnel.
Choose the persistence strategy
For a pure cache, disable persistence to gain performance. For a job broker where loss is unacceptable, enable AOF with appendfsync everysec: a good trade-off between durability and throughput. Combine RDB + AOF for fast restarts and reliable journaling.
Connect your application
Launch with docker compose up -d and test with docker compose exec redis redis-cli -a VOTRE_PASS ping. Point your application to the internal Docker network rather than a public IP, for both latency and security.
Monitor memory
Monitor used_memory and evicted_keys via redis-cli INFO. If evictions rise, increase the RAM or refine the policy. Set up an alert when memory usage exceeds 80% of maxmemory.
Monitor the keyspace_hits / keyspace_misses ratio via INFO stats: a low hit rate means your cache is undersized or your TTLs are too short. For critical workloads, deploy Redis Sentinel across three VPSs to obtain automatic failover: if the master goes down, a replica is promoted without intervention, and your applications are redirected via the Sentinel service.
The official documentation
For advanced configuration and tool-specific options, refer to the official Redis documentation. This guide covers going live on a VPS; the vendor's documentation remains the reference for fine-tuning, major upgrades, and specific use cases.
