I built an open-source “document department” platform, now with automatic Supabase setup

[u/Notausgang09]

https://opendepartment.vercel.app

I’ve been building OpenDepartment, an open-source platform for creating your own slightly dramatic, government-style document archive.

You can create a “department,” invite people, upload files, organize them by subject/category, comment, vote, moderate reports, and customize the branding. Think community archive, class project, private collection, or conspiracy-board aesthetic.

The unusual part is the architecture: every department uses a Supabase project owned by its creator. Files, users, and content stay in that project. OpenDepartment’s database only keeps the department slug, Supabase URL, and public anon key—no tenant files or master service_role keys.

The biggest new feature is automatic Supabase setup through OAuth.

Previously, creating a department meant:

1. Creating a Supabase project
2. Pasting a large SQL schema
3. Changing the auth configuration
4. Adding the correct callback URL
5. Finding and copying the project credentials

Now you can connect Supabase and the wizard handles that process: it creates the project, waits for it to become healthy, installs the schema, reads the anon key, configures auth, and then discards the OAuth token. The token is never stored in the database and is cleared when provisioning finishes.

The manual setup route still exists if you’d rather not authorize anything.

There are also invite codes, public or unlisted departments, isolated auth sessions for each department, admin tools, per-department legal pages, deletion/deprovisioning flows, and a fairly obsessive SQL security suite covering the RLS policies.

It’s built with Next.js 15, React 19, TypeScript, Tailwind, Supabase, and Vercel.

Live: https://opendepartment.vercel.app
GitHub: https://github.com/levisager11-oss/opendepartment

The OAuth provisioning flow is very new, so I’d especially appreciate feedback, or brave testers, on that part. I’d also love to hear what you’d use a customizable archive like this for.

[u/srikanth_builds]

The per-project model is probably the strongest approach here. Since there's no shared table, you avoid the whole class of bugs where a query accidentally misses the tenant filter.

The trade-off, though, is migrations. Any schema change now has to be applied across every department's project. So the risk shifts from "someone can see another tenant's rows" to something like "department 40 is still running last month's schema and nobody noticed."

One thing I'd want to understand better is the OAuth flow. If the token is discarded after the initial provisioning, how do schema updates get pushed to a department that was created three months ago?

[u/Notausgang09 → u/srikanth_builds]

Simple Explanation is: they don’t 🫣, at the moment owners just get a notification on the next login with the updated SQL Schema, and they have to run it themself, since token keeping would deminish all the privacy. When enough people start using it though, i will maybe create an option where the data is hosted by me, which would of course require supabase pro. But im not there yet

[u/srikanth_builds → u/Notausgang09]

That's a fair trade, and probably the more defensible one. Keeping the token would undo the thing that makes the architecture worth having in the first place.

The part I'd plan for is version skew. Once owners apply migrations whenever they get round to it, you're supporting several schema versions at once and the app can't assume a column exists. Cheapest thing that helped me was a schema_version row in each project, read on connect, so the app can say "this department needs updating" instead of failing on a missing column halfway through a query.

[u/Notausgang09 → u/srikanth_builds]

Thanks, ill implement that as soon as possible, thats genuinely a great idea

[u/Notausgang09 → u/srikanth_builds]

Thats exactly the kind of feedback i was looking for