Today we're releasing Supabase Studio. The same Dashboard that you're using on our Platform is now available for Local Development and Self-Hosting.

Let's get the obvious question out of the way - why wasn't it already open source?

When Ant and I started Supabase the codebase was one large monorepo which contained everything from the dashboard to cloud infrastructure code to experimental code. This is our preferred development setup - we like to keep all code in one place so that we have a single source of truth and tightly coupled CI workflows.

The original Dashboard really wasn't much except a couple of buttons which allowed our Alpha users to start and stop a Supabase project - back then only a PostgreSQL connection string.

Then time went on, and we started gaining traction - a lot faster than expected. The nice thing about building for developers is that they are very vocal about the features they want to see next. And so we kept shipping - a SQL editor, a Table view, User management, auto-generated Docs, and everything else you can find on the Dashboard today.

We've been planning to make the Dashboard public for a long time now, starting with Supabase UI, supabase/grid, and a standalone PR for Supabase Studio. But as feature requests kept rolling in it became a Sisyphean task to maintain separate code bases.

After the last Launch Week, we decided to prioritize the Studio.

We investigated a few different approaches used in the open source world. There are three popular strategies that we found amongst OSS projects and some of our YC alum:

• Maintain separate code bases. Pluck changes from one to another.
• Keep two repos in sync using some mixture of git submodules or a tool like copycat
• Use the same codebase, abstracting platform-specific code behind an API and feature flags.

Our frontend team experimented with the first two approaches where they plucked (injected, merged, and wrangled) code for our Platform. Time-to-production become a lot slower, an unacceptable outcome at Supabase.

Eventually we decided to open source all the frontend code, a shared codebase for both the Platform and Self Hosting.

Special shout out

Sentry do a fantastic job of documenting their strategy for managing a shared codebase and served as a great model for Supabase.

For the past week, the dashboard you've been using on the Platform has been deployed from our main repository.

This fits one of our core philosophies at Supabase: do less. Less code to manage means less bugs. Fewer codebases means faster shipping.

It also fits the development philosophy of every other part of Supabase: building in public, "warts and all".

This is a huge step forward for the community. Supabase users can now spot a bug, fix it in the open source repository, and have it shipped to both the Platform and Self-Hosted environments - all in a few hours.

Let's jump into some of the technical implementation for Supabase Studio.

Tech stack#

Studio is a Javascript application with a few key pieces of technology:

• Next.js - A frontend Javascript framework built with React.
• Tailwind - A utility-first CSS framework.
• Supabase UI - Our own component library.
• MobX - A state management library.
• A host of other useful libraries, including Radix UI, Lottiefiles, react-grid-layout, and zxcvbn.

What's included#

Studio is designed to work with existing deployments - either the local hosted, docker setup, or our CLI. It is not intended for managing the deployment and administration of projects - that's out of scope.

The features exposed on Studio for existing deployments are limited to those which manage your database:

• Table & SQL editors.
• Database management: Policies, roles, extensions, replication.
• API documentation.

Check out the full instructions in our Studio Readme.

We are live and launched on Product Hunt#

Our new open source Studio is also on Product Hunt right now. If you like what you see, please give it an upvote and a review.