Self-Host Redis vs Managed: What a Side Project Needs

For a side project or a small product, self-hosting Redis on your own box beats managed Redis, and it is not close on price. Managed Redis services routinely start at fifteen to fifty dollars a month for a tiny instance, which is more than the VPS running your entire app. Redis is one of the easiest things in the world to run: pull the image, set a password, mount a volume, done. The case for managed only shows up when you need high availability across regions, and most side projects never do.

When should I self-host Redis?

Self-host when Redis is a cache, a session store, a rate limiter, or a job queue backend for a single-box app. Which is to say, almost always for a side project. In those roles Redis is doing exactly what it was built for, and losing the instance for a minute during a restart is annoying but not catastrophic. A cache repopulates. A queue that persists to disk survives a reboot.

Running it is trivial. Add a Redis service to your Compose file, give it a password, point your app at it over the private network, and never expose the port to the internet. It uses a few megabytes of RAM at rest. It sits on the same box as your app, so latency is a fraction of a millisecond instead of a network round trip to a managed endpoint. That colocation is a real performance win people forget about, and it is the same logic behind keeping Postgres on the same box as the app to start.

The setup is an afternoon at most, and it folds neatly into a stack you already control, which is the whole point of running on HostSSH rather than renting every piece.

When is managed Redis actually worth it?

Managed earns its price in one situation: when Redis holds data you genuinely cannot lose or cannot be down, and you do not want to build the failover yourself. If Redis is your primary datastore rather than a cache, if you need automatic replication across availability zones, or if a minute of cache downtime translates directly into lost revenue at scale, pay for managed. You are buying replication, failover, and someone else's pager.

But be honest about which case you are in. Most people reach for managed Redis because it felt like the responsible choice, not because they mapped their actual durability needs. A cache does not need multi-region replication. A session store for a few thousand users does not either. If you cannot describe the specific outage managed Redis prevents for you, you are paying a premium for a fear, not a requirement. That is the same trap I describe in the managed vs self-hosted decision: convenience marketed as safety.

Self-hosted Redis without losing your data

The one legitimate worry with self-hosting is durability, and Redis has two answers built in. RDB snapshots dump the dataset to disk periodically. AOF logs every write and replays it on restart. For a cache you may not care. For a queue or a session store, turn on AOF with appendfsync everysec, which gives you at most one second of data loss on a crash for almost no performance cost.

Back up the Redis data directory alongside your database backups so a full box loss does not take your queue with it. If you already run a backup routine, this is one more path to include, covered in own your backups when you self-host. Set maxmemory and an eviction policy so a runaway key does not consume the whole box. Those three settings, persistence, backup, and a memory cap, cover the durability gap that managed services charge you monthly to solve.

Run the cost math before you default to managed

Here is the comparison people skip. A managed Redis instance at thirty dollars a month is three hundred and sixty dollars a year, forever, for something that adds a few megabytes to a box you are already paying for. Self-hosted, the marginal cost is effectively zero because Redis rides along on your existing VPS. Over a couple of years that is real money for a side project, and it buys you nothing you needed.

The pattern generalizes. Every managed add-on looks cheap in isolation and expensive in aggregate, which is exactly how a cloud bill creeps, a dynamic I broke down in why your cloud bill climbs. Redis is the clearest case to reverse first because it is so easy to run yourself. Self-host it, cap the memory, turn on persistence if you need it, back it up, and put the savings toward something that actually moves your project forward.