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.
Logging in for the first time
Open the URL: RedisInsight appears straight away, WITHOUT asking for any credentials at all (you only accept the terms of use on the first screen), and your local Redis database is already accessible there for reading and writing. Do not attach a public domain to this interface without protection in front of it.
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.
