supabase CLI: three betas in one day, a Go implementation inside a TypeScript monorepo, and no license file

The README states a license the repository root does not contain

The last section of the file says Supabase CLI packages are released under the MIT license. The repository root does not contain a license file. The package metadata carries no recognised license value either, so the only statement of terms in the repository is a sentence at the bottom of the README.

That is not a technicality for anyone shipping this as a dependency in a product with an open source audit behind it. A single sentence is not the same artifact as a license text with a copyright line, and it does not say which packages it covers when the repository publishes more than one.

The honest position is that the terms are asserted but not evidenced in the tree, so ask the project directly and get the answer in a file you can point a scanner at. Do not infer MIT from the sentence alone, and do not infer anything at all from the empty metadata field; the two disagree.

Three betas in one day, and no stable release in the list

The three most recent releases are all pre-releases of the same version: beta.5, beta.6 and beta.7 of 2.120.0, published on the same date within a few hours of each other, with beta.6 and beta.7 ten minutes apart. The default branch is `develop` and the last commit is dated 2026-10-02, the same day as the newest tag.

So the visible release feed for this project is currently a beta train, not a line of stable versions. That is normal for a tool that ships many small changes, and it has a practical consequence: the version you get depends on which channel you installed, and the beta channel is separately addressable in both package managers rather than being a flag on the same artifact.

The naming also encodes the channel. A beta tag looks like a stable tag with a suffix, and the install commands ask for that suffix explicitly, so a lockfile pins a channel rather than a line.

The project labels its own one line installer

The installation block offers five routes, and the comments in it are as informative as the commands.

The first is a remote script piped straight into a shell:

# YOLO
curl -fsSL https://raw.githubusercontent.com/supabase/cli/main/install | bash

The comment above that line is the project's own word for it, which is more honest than most installers manage. Two details follow from the URL: it fetches from a `main` branch path while the repository's default branch is `develop`, and nothing in the process pins or verifies what was downloaded.

The package manager routes are tidier. The npm line installs as a development dependency rather than globally, with a note that bun, pnpm and yarn work the same way, and a separate line for the beta channel. On macOS and Linux there are three Homebrew options with different freshness: the tap is described as always up to date, the official formula as possibly delayed, and a tap beta formula for the beta channel. Windows goes through a Scoop bucket added from the project's own repository. Linux packages are also on the releases page, with community packages available through two other package managers.

A TypeScript CLI that keeps a Go implementation beside it

The developing section describes a pnpm monorepo in which the published package lives in `apps/cli`, and then a table of source entry points. Three of the five entries are ordinary packages: a local stack runtime, a config schema with generated types, and a typed client for the management API.

The fourth entry is the interesting one. `apps/cli-go` is described as the Go CLI source used by the CLI, so the command line tool you install is a TypeScript and Bun package that relies on a Go component underneath it. The package scripts show the shape of that relationship: the unit test run explicitly filters the Go package out, and the root workspace is private with the published package named separately.

That arrangement has consequences for anyone building on the tool. The distributed artifact is not self-contained in one language, the Go side is outside the workspace unit test sweep, and a change that touches both halves is reviewed and tested as two projects.

External pull requests are closed automatically without a labelled issue

The contributing section sets a gate that is worth reading before writing any code. Open an issue first and wait for a maintainer to add an `open-for-contribution` label before starting work. External pull requests that do not link a labelled, open issue are closed automatically.

So the workflow has a human step in it that cannot be automated or rushed: someone has to triage the issue and decide it is a good contribution. The stated preference is for focused changes with a clear problem, a small surface area, and tests that match the user facing behavior.

The mechanical requirements are spelled out in detail. Repository wide quality checks run from the root, then the relevant package tests run from each workspace you touched, and any touched workspace that declares a type check script runs that too. Pull request titles must follow conventional commits, with the example given being a fix scoped to the cli area about linked projects without cached service versions. So the bar is: one problem, matching tests, a typed title.

Nine command families, and a description that promises more than the file shows

The command tour is short by design. A local stack starts with init, start and status, or from a template with bootstrap, and the file names what that stack contains: Postgres, Auth, Realtime, Storage, Edge Functions and the Supabase APIs. Linking to a hosted project is two commands, login and link. Migrations use a new subcommand to create one, plus diff, push and reset. Functions use new, serve and deploy. Types are generated with a local or a linked flag.

What is missing from that tour is what the project's own one line description advertises: Postgres backups. Nothing in the command sections covers taking or restoring a backup, which means either the tour is deliberately partial or the capability lives entirely in the reference. The file resolves that by pointing at `--help` on any command and at the hosted documentation, so the tour is an illustration rather than a reference.

The `bootstrap` command is also the only one whose mechanism is not obvious from its name, and it gets a single line about starting from a template.

Reference repositories as submodules, and a local registry for testing

After a fresh clone the instructions tell you to install reference repositories used for agent and developer inspection, which corresponds to the submodule configuration and the reference directory at the root. So part of the setup is checking out other projects to look at them, which is a different kind of dependency from the package manager ones and one that will surprise anyone expecting a self contained build.

The rest of the root is a large but coherent toolchain. Tasks run through a task runner configured in one file, versions are pinned twice over with a Node version file, a Bun version file and a mise configuration with its own lock file, and there is a patches directory for patched dependencies.

Quality is checked by five separate passes wired into one command: type checking, linting, formatting, an unused dependency and export check, and a second lint configuration dedicated to the Effect code, which is also patched at prepare time. Beyond that there are two checks that have no equivalent in a typical repository: a configuration API comparison script and a local registry configuration, which is how the workspace publishes packages without publishing them anywhere public.

Editorial conclusion

supabase CLI fits anyone working on a Supabase project who wants the same migrations, types and edge functions to move between a laptop stack and a hosted project, and who will read the per-command help rather than the README. Four things to settle first. Licensing is unresolved on the evidence in the repository: the README states MIT while the package metadata carries no recognised license and there is no license file at the root, so get that answered in writing before shipping a dependency on it. Channels differ in freshness, since the Homebrew tap is described as always current while the official formula may be delayed, and the beta channel is separate again for both package managers. The one-line installer pipes a remote script into a shell and the project labels it that way itself. And the contribution gate is strict enough to plan around: an external pull request is closed automatically unless it links an issue a maintainer has labelled open for contribution.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. supabase/cli on GitHub