Redis Sentinel
Highly-available Redis with automatic failover - one master, two replicas, three sentinels.
One-click deploy, from $13/mo on a Miget plan.
Redis Sentinel adds high availability to Redis: if the master goes down, the sentinels detect it, elect a new master from the replicas, and reconfigure the topology automatically. This template runs one master, two replicas, and three sentinels (quorum 2) - the standard HA layout.
One image plays all three roles, selected by an environment variable; the entrypoint builds each node`s command and the sentinel config from env. Sentinels are configured to resolve hostnames (service DNS) rather than raw IPs, which is what makes failover report a usable address on a multi-pod network. Verified locally: the master sees both replicas and all three sentinels agree.
Clients connect through Sentinel, not the master directly - a Sentinel-aware client (ioredis, redis-py, Lettuce, go-redis) asks a sentinel for the current master and is rerouted automatically on failover.
Upstream project: Redis
#what you get
- Automatic failover: replica promoted when the master dies
- One master, two replicas, three sentinels (quorum 2)
- Hostname-based discovery - works on a multi-pod network
- Transparent to Sentinel-aware clients
- All internal-only, password-protected
- Redis 8 is AGPL-3.0
#topology
| Service | Role | Public |
|---|---|---|
| redis-master | primary (:6379) | no (internal) |
| redis-replica-1/2 | replicas (failover targets) | no |
| redis-sentinel-1/2/3 | monitors + electors (:26379) | no |
#miget sizing
// this stack needs
1.9 GiB RAM · 15 GB disk · 6 services
Master and replicas hold the full dataset in memory (size accordingly); sentinels are tiny (128 MiB). Six services, all internal.
Hobby - recommended fit
$13/mo
1 vCPU · 2 GiB · 50 GiB disk
Headroom for your own apps: 2 GiB at $19/mo
Professional - production
$43/mo
2 vCPU · 4 GiB · 25 GiB disk
Dedicated resources, production SLOs - plan details
One Miget plan is a fixed pool of compute - the whole stack (managed databases included) deploys inside it, and anything left over runs your other apps. No per-service or per-seat math.
#vs. the managed service
What the hosted equivalents charge, against the flat Miget plan this stack fits on. Prices as of June 2026, sources linked.
| Service | Plan | Monthly | What you get |
|---|---|---|---|
| Redis Sentinel on Miget ★ | 2 GiB plan | $13 | this whole stack, flat - no usage meters, and room left for your own apps |
| AWS ElastiCache | Multi-AZ (2 nodes) | ~$24 | primary + replica on-demand/mo for the smallest size |
| Redis Cloud | HA (multi-AZ) | ~$28 | highly-available tier, scales with memory |
Managed HA caches bill per node per AZ; this runs the whole failover topology on one flat plan.
#vs. other PaaS
Estimated monthly cost of running this exact stack (1.9 GiB RAM, 15 GB disk, 6 containers) elsewhere, from published June 2026 rates.
| Platform | Est. monthly | Notes |
|---|---|---|
| Miget ★ | $13 flat | compose stacks first-class: one deploy, dedicated vCPU, managed Postgres/Valkey, volumes and TLS all included in the plan |
| Heroku | ~$94 | no volumes; nothing between 1 GB ($50) and 2.5 GB ($250) dynos - 2 GB containers cost far more than shown |
| Render | ~$46 | per-service instances (0.5 GB $7, 2 GB $25) - every container is its own paid service |
| DO App Platform | ~$35 | no persistent volumes - stateful containers need managed DBs/Spaces (base $5 Spaces included here) |
| Railway | ~$21 | usage-based ($10/GB RAM-mo); vCPU billed separately at $20/vCPU-mo on top |
| Fly.io | ~$14 | cheapest sticker price - but burstable shared CPUs (1/16 core; dedicated vCPUs cost ~2-3×), no compose deploys (one app per container, manual wiring), managed DBs billed extra |
Estimates assume RAM fully allocated at published on-demand rates - and sticker price isn't the whole comparison: the cheaper rows buy burstable shared CPUs, per-service wiring instead of a compose deploy, and managed databases billed separately. Heroku and DO App Platform have no persistent volumes at all - stateful stacks like this one need workarounds there.
#deploy it
On Miget
- Create a Compose Stack in app.miget.com pointing at the templates repository
- Set the stack path to
redis-sentinel -
Set the required variable:
REDIS_PASSWORD, shared by master, replicas, and sentinel auth
- Deploy. Miget layers
compose.miget.yaml(RAM, privacy, volumes, managed services) automatically
Locally first?
Every template is portable, vanilla Docker Compose - the Miget overrides are ignored locally:
git clone https://github.com/deployable-sh/stacks
cd miget-compose-templates/redis-sentinel
docker compose up -dSame files, same behavior. The template README covers connection strings and scaling notes.
#faq
When should I use Sentinel vs Cluster?
Sentinel gives you high availability (automatic failover) for a single dataset that fits on one node. Use redis-cluster instead when the data or throughput exceeds one node and you need sharding across multiple masters.
How do clients connect?
Through Sentinel, not the master directly. Point a Sentinel-aware client at redis-sentinel-1:26379, redis-sentinel-2:26379, redis-sentinel-3:26379 with master name "mymaster"; the client discovers the current master and follows failovers.
Does failover actually work on a PaaS?
Yes - the sentinels resolve service hostnames instead of pod IPs, so after a promotion they report a DNS name clients can reach. This template was smoke-tested locally: master with two connected replicas and three mutually-aware sentinels.
Ship Redis Sentinel today
One compose stack, 1.9 GiB of RAM, from $13/month flat, and it runs on your laptop with the same files.