Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
I have an idea I wanted to share with you all (github.com/orgs)
1 point by prassamin 31 days ago | hide | past | favorite | 2 comments


### Discussion Type

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”


404




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: