I spent some time looking through the self-hosted side of the repo and wanted to float an idea that feels pretty valuable from an OSS contributor point of view.
The short version: I think there is room for a meaningful project around making self-hosted Studio feel more complete for developer workflows.
What stood out to me is that the backend support already seems to be there in a few places. There are self-hosted paths for things like logs/analytics access, lints/advisors, migrations, generated types, and project settings. But in the Studio product surface, the experience still feels a bit uneven. Some things are exposed, some are hidden, and some seem to depend on platform-oriented assumptions.
That made me think the real opportunity here is probably not "full feature parity" in the abstract, but something more practical:
By that I mean improving the workflows that self-hosted and local users actually reach for day to day, for example:
The reason this feels worthwhile is that it builds on things that already exist instead of proposing a completely new subsystem. It also seems aligned with one of Supabase's biggest strengths: the open source and self-hosted story.
If I were to break it down, I’d probably approach it like this:
I also think this is the kind of work that can be done in a series of smaller PRs instead of one huge change.
If the scope needs to start smaller, I think a very reasonable first slice would be:
That seems like a good entry point because debugging is one of the places where self-hosted users feel friction quickly, and there already appears to be some supporting infrastructure in the repo.
So I guess the main question for maintainers is:
Would this be a useful direction for outside contribution?
And if yes, would it be better to start with:
If this is interesting, I’d be happy to turn it into a more concrete implementation plan and start with a scoped first PR.
Mandar Joshi proposes enhancing the self-hosted developer experience in Supabase Studio. The suggestion focuses on improving workflows such as migrations, generated types, and observability for self-hosted users. The proposal includes a capability-based model to manage UI visibility and suggests starting with observability and diagnostics as a first step. Mandar seeks feedback on whether this direction is useful for contribution.