Question
### Discussion Content
Hey
I have an idea I wanted to share with you all.
I’ve been using *Upstash* for a long time across a bunch of projects, and honestly, I really like it. Redis-over-HTTP has saved me so much pain with serverless stuff.
This idea actually came up while working on a *client project* recently.
The client gave me a *VPS* and wanted everything to live there - including Redis. That’s where I got stuck thinking:
> “If Redis already exists on the client’s VPS, how do I still get the Upstash style features?”
Using Upstash directly felt a bit awkward in this case:
* it becomes an *external dependency* the client has to maintain later * billing, accounts, ownership - all outside their infra * but at the same time… I really wanted the HTTP API + serverless-friendly behavior Upstash gives
That’s when I started wondering:
What if there was a way to:
* point something at *any Redis* (VPS / on-prem / managed) * and still get *Upstash like HTTP endpoints* * without vendor lock-in * and something the client could fully own or self-host?
So I started hacking on a small experiment around that idea: an *open-source, self-hostable Redis-over-HTTP proxy* (working title: Redion).
It’s very early and very much a “thinking out loud” phase right now.
I’m mostly curious:
* Have you run into this kind of situation before? * How do you handle Redis + serverless when Redis isn’t “yours” to choose? * Does “bring your own Redis but keep HTTP semantics” sound useful? * Any obvious downsides or red flags you see immediately?
Not trying to replace or hate on Upstash at all - this question only came up because I’ve been happily using it for so long Just wanted to sanity-check the idea with other devs before going further.
Would love to hear thoughts, even if the answer is “nah, I’d never use this and here’s why”