basejump gives a Supabase app accounts, teams and RLS permissions

The first line of the README says the project is unmaintained

Before anything else, the notice at the top of the Basejump README: this project is unmaintained. It is still useful as an example for how you can implement team accounts with Supabase, particularly the migrations. But stuff like billing is better solved now using the official Supabase sync from Stripe.

That sentence decides how to read the rest of this repository, so it is worth taking apart. The value that remains is in the SQL and in the example it provides, and the project names that part specifically. The migrations are a readable reference for the account model, and they are the part that has not been overtaken.

The part that has been overtaken is billing, and the project says why: the official Supabase sync from Stripe now does that job. The last push to the repository was on 2026-08-06, and the most recent tagged releases are older still, with v2.0.3 on 2024-01-14 resolving import issues in billing functions, v2.0.2 on the same day fixing a type issue in Stripe functions, and v2.0.1 on 2023-12-04 moving the Deno functions. The repository is not archived, so the code is still reachable, but the release history stopped in 2024.

The licence field on the repository says MIT, so anything you copy from it comes with a permissive notice attached.

Personal accounts and team accounts are the two billing units

Basejump adds personal accounts, team accounts, permissions and billing support to Supabase Auth, and the account model is the part of the design that still makes sense to copy.

Personal accounts are automatic. Every user that signs up using Supabase auth automatically gets their own personal account, and billing on personal accounts can be enabled or disabled. There is no provisioning step, no separate table to join, and no admin action needed to give a new sign up a place to put data.

Team accounts are the billable unit. They are billable accounts that can be shared by multiple users, and they can be disabled entirely if you only wish to allow personal accounts. Billing on team accounts can also be disabled independently of the personal side.

That is a deliberate piece of modelling, and it is the reason the project calls itself an example worth reading. Most applications that need teams end up with three concepts, the user, the organisation, and the membership linking them, plus a special case for the single user who is their own organisation. Basejump encodes that shape directly in the database, with personal and team accounts as first class rows and memberships pointing at them.

The toggles for enabling and disabling billing on each side are what make the model reusable. A product that wants a free tier with a paid upgrade path can turn on team billing and leave personal billing off, and the schema supports that without a fork.

Permissions are plain RLS with convenience methods on top

The permissions story is deliberately unremarkable, and that is the point.

Permissions are handled using RLS, just like you are used to with Supabase. Basejump provides convenience methods that let you restrict access to rows based on a user's account access and role within an account.

That is the whole claim. There is no new policy language, no permission DSL and no custom authorisation layer to learn or to debug. A developer who already writes row level security policies in Postgres writes the policies for this project, and the convenience methods exist only to avoid repeating the same joins to account membership tables in every policy.

This is where the migrations earn their keep in an unmaintained project. A policy that has to say a user may read a row when they belong to the account that owns it, and may write it when their role in that account permits it, is a policy that has to resolve two joins. Repeating that across every table in an application is where mistakes accumulate, and a set of helper functions that centralise it is the kind of thing that stays useful after the surrounding project moves on.

The stack is PostgreSQL, with PLpgSQL recorded as the primary language, and the whole implementation lives in the supabase/ directory of the repository. That means the deployment unit is a set of migrations applied to a Supabase project, not a package you install in your application.

Billing lived in Deno edge functions and now has a better answer

Basejump provides out of the box billing support for Stripe, and the project asks that if you add your own provider you consider contributing it so others benefit. The billing code itself lives in separate repositories, with Basejump core and Basejump edge functions and billing functions split across the main repository and basejump-deno-packages.

The release notes show how that code moved. v2.0.1 moved the Deno functions, and the two releases that followed on 2024-01-14 were fixes rather than features, one resolving import issues in the billing functions and one fixing a type issue in the Stripe functions. Two same day patch releases is what a team does when it is closing a problem rather than shipping a roadmap.

The current guidance in the README is that billing is better solved now using the official Supabase sync from Stripe. That is a shift in the answer to a common question, and it is the clearest example of what an unmaintained project means in practice. The old approach remains in the repository and still works if your Stripe and Supabase setup matches what it expected, but a new project that needs subscription billing in 2026 has a first party path, and this repository is not it.

The same logic applies to the permissions and accounts work. It is not obsolete, it is just no longer where the maintained answer lives.

The pgtap suite is the part you can still run today

Basejump includes comprehensive pgtap testing for all included functionality, and it is not enabled by default in case that is not your jam. Running the tests takes three setup steps.

First, install the extension.

create extension pgtap with schema extensions;

Second, install dbdev by following the directions at database.dev. Third, install the helper package.

select dbdev.install('basejump-supabase_test_helpers');

Then the suite runs with a single command.

supabase test db

There is a point in that list that matters more than the rest. The testing tools are published separately, and the README states that you do not need to be using Basejump to use the testing tools. They live at database.dev/basejump/supabase_test_helpers.

That makes them the piece of this repository with the longest useful life. A test harness for Supabase functions and schema is infrastructure rather than a product, it does not depend on the account model being the way you want it, and it does not compete with anything. If you are working on Supabase today and want pgtap tests for your own functions and schema, this is the part to take.

The same applies to the standard request for contributions, which asks for pull requests with changes that are well tested and documented.

A Next.js starter gets you to a running app quickly

The quick start is a guide on usebasejump.com rather than a file in the repository, but there is a ready made Next.js template that cuts a lot of it out.

yarn create next-app -e https://github.com/usebasejump/basejump-next

After that you add your Supabase URL and anon key to a .env.local file, with an example in the .env.example file. One detail worth knowing up front: create-next-app forces you to install the template into a nested directory, and the README notes that you can move the contents of the directory to the root of your project if you would like.

That is a small thing, but it is the kind of detail that saves time when you are following a guide and the paths do not match. The template is described as fleshed out, which for an unmaintained project is worth checking rather than assuming, since a starter that has not been updated against current Supabase Auth conventions may need work before it is a good starting point.

The repository itself is small. The top level holds the .github directory, a .gitignore, LICENSE.md, README.md and the supabase directory, and that is the whole project. There is no runtime service to deploy and no package to keep in sync with your app.

Where Basejump is the wrong tool

The clearest case against using it for a new build is the notice at the top of the README. If you are starting a product in 2026 and need subscription billing, the project itself tells you to use the official Supabase sync from Stripe instead. The billing functions in this repository were last touched in January 2024, and the Deno based edge function approach has had two years for the platform to move past it.

The second case is an application that does not need teams at all. If every user just needs their own personal space, the account model is overhead, and Supabase Auth with row level security on your own tables is less to understand and less to maintain.

The third case is a team that wants an actively supported dependency. An unmaintained repository is not a problem if you are reading it as documentation, and it is a liability if you are depending on it to keep working. Nothing here is a blocker for a project that reads the migrations and moves on, because MIT licensed SQL is MIT licensed SQL. The difference is entirely in what you expect to happen when Supabase changes something.

The fourth case is a team that is not on Supabase at all. There is nothing in this repository that works outside Supabase Auth and Postgres migrations, so the account model has to be reimplemented from scratch, and the effort is no longer saved.

Editorial conclusion

Adopt the basejump migrations as a reference implementation if you need team accounts on Supabase Auth and want to read how accounts, memberships and RLS helpers fit together, since the SQL is readable and the project is MIT licensed. Do not start a new billing integration on top of it, because the README states that billing is better solved now using the official Supabase sync from Stripe, and the last push to the repository was on 2026-08-06 with the most recent tagged release, v2.0.3, dating from 2024-01-14. If you do take the test helpers, install pgtap into the extensions schema, install dbdev, add the basejump-supabase_test_helpers package and run supabase test db, and note that those helpers do not require you to use Basejump itself.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. usebasejump/basejump on GitHub