Why this boilerplate skips Redis
1 min read
by The LaunchKit team
Every extra piece of infrastructure is something you provision, monitor, patch and pay for. For a solo founder, that overhead adds up fast. So the boilerplate runs on one database.
Three jobs Redis usually does
- Background jobs - handled by Solid Queue, stored in your PostgreSQL database.
- Caching - handled by Solid Cache.
- WebSockets / real-time - handled by Solid Cable (this powers live notifications).
All three ship with Rails 8 and live in the same database you already have. No second service, no extra connection string, no Redis bill.
What you gain
Before: app + PostgreSQL + Redis + a worker host
After: app + PostgreSQL
Simpler deploys (Kamal or Heroku), fewer moving parts, and one place to back up.
When would you add Redis back?
At real scale - tens of thousands of jobs per minute, or caching hot keys at very high throughput - a dedicated Redis can outperform the database. The point isn't "never use Redis"; it's "don't pay for it on day one". Swapping an adapter later is a config change, not a rewrite.
#rails
#infrastructure