Open sdnts opened 4 years ago
The main options that we have considered for packaging so far:
What's the use case for a self-hosted Studio?
Most people I've heard from, want to use Studio as an admin dashboard for their DB, that's what I mean by "hosted version". Not sure if the Cloud version is the same thing or not.
For your consideration, @madebysid: https://tauri.studio/
Built using Rust :) and much smaller, snappier, apparently. https://news.ycombinator.com/item?id=27155831
Now that we have released a hosted version of our cloud app, I guess we can close this issue :)
@martzoukos now that this hosted version does no longer exist: any new recommendations? :D
Hey I'd love to see some movements from this. Our use case is that
I haven't did much digging regarding the cloud version there but it requires the db to be public ? Which is not ideal
Definitely one of those “value-add” features for us as well. Yes, we can spin up localhost
, and, yes, we can access and modify the data that way... but wouldn’t it be so much nicer if we didn’t have to.
Down the road, it would be even cooler if we could have various levels of access built-in: support teams being able to only read or read/write certain tables, for example.
Been seeing some interest from people willing to host a (secured) instance of Studio.
I have two use cases in mind:
They want to hide it behind an authenticated endpoint, AKA they handle authentication: This would require them to be able to override all static asset paths from the CLI. Fortunately, this option already exists in StudioServer, so it is (hopefully) only a matter of exposing it to the CLI
They expect Studio to handle authentication: This is more complicated and honestly might need some product intervention.
If anyone else reading this can think of other use cases, please leave them down below!