Supabase CLI

The Supabase CLI runs the entire Supabase stack on your own machine or in a CI environment, so you can build and test locally, then connect your project to a hosted one when you're ready to deploy.

• Quickstart is the two-command version, if you already have the CLI and a container runtime.
• Set up a local project installs the CLI and brings the stack up on your machine. Start here if you haven't run it before.
• Connect to a hosted project links your local directory to a project on the Supabase Platform.
• Change your CLI version updates the CLI and switches between stable and pre-release builds.
• Telemetry covers what the CLI collects and how to opt out.

Quickstart

With two commands, you can set up and start a new local project:

1. Run supabase init to create a new local project.
2. Run supabase start to launch the Supabase services.

Set up a local project

Install the CLI, bring the Supabase stack up on your machine, and stop it when you're done.

Install the Supabase CLI [#installing-the-supabase-cli]

brew install supabase/tap/supabase

scoop bucket add supabase https://github.com/supabase/scoop-bucket.git
scoop install supabase

brew install supabase/tap/supabase

Run a local Supabase project [#running-a-local-supabase-project]

The most common thing you do with the CLI is run the full Supabase stack (Postgres, Auth, Storage, and the rest) on your own machine. That stack runs in Docker containers, so you need a container runtime installed first. On Windows and Linux, follow the official guide to install and configure Docker Desktop. In a coding agent sandbox or on a CI runner with no container engine, the experimental native runtime runs each service as a process instead. It supports Linux and macOS on Apple silicon. For platform requirements and setup, see Docker and native runtimes.

On macOS, we recommend OrbStack instead of Docker Desktop. It's a drop-in replacement that handles extended file attributes (xattrs) on mounted volumes and container networking more reliably than Docker Desktop. It also starts faster and uses less CPU, memory, and disk, which makes a noticeable difference when running the full Supabase stack.

Alternatively, you can use a different container tool that offers Docker-compatible APIs:

To bring the stack up:

1. Start your container runtime.

2. Open a terminal in the directory where you want to create your project.

3. Initialize the project:

   supabase init

   The command creates a supabase directory, which is safe to commit to version control. init creates local files only: it doesn't sign you in or connect the directory to a project on the Supabase Platform. To connect one, see Connect to a hosted project.

4. Start the Supabase services from the same directory:

   supabase start

The first run takes time while the CLI downloads the Docker images. It pulls the entire Supabase stack, plus a few extra images useful for local development, such as a local SMTP server and a database diff tool.

Access your project's services

After all the Supabase services are running, the CLI prints your local credentials. The output looks like this, with the URLs and keys you use in your local project:

Started supabase local development setup.

╭──────────────────────────────────────╮
│ 🔧 Development Tools                 │
├─────────┬────────────────────────────┤
│ Studio  │ http://127.0.0.1:54323     │
│ Mailpit │ http://127.0.0.1:54324     │
│ MCP     │ http://127.0.0.1:54321/mcp │
╰─────────┴────────────────────────────╯

╭──────────────────────────────────────────────────────╮
│ 🌐 APIs                                              │
├────────────────┬─────────────────────────────────────┤
│ Project URL    │ http://127.0.0.1:54321              │
│ REST           │ http://127.0.0.1:54321/rest/v1      │
│ GraphQL        │ http://127.0.0.1:54321/graphql/v1   │
│ Edge Functions │ http://127.0.0.1:54321/functions/v1 │
╰────────────────┴─────────────────────────────────────╯

╭───────────────────────────────────────────────────────────────╮
│ ⛁ Database                                                    │
├─────┬─────────────────────────────────────────────────────────┤
│ URL │ postgresql://postgres:postgres@127.0.0.1:54322/postgres │
╰─────┴─────────────────────────────────────────────────────────╯

╭──────────────────────────────────────────────────────────────╮
│ 🔑 Authentication Keys                                       │
├─────────────┬────────────────────────────────────────────────┤
│ Publishable │ sb_publishable_...                             │
│ Secret      │ sb_secret_...                                  │
╰─────────────┴────────────────────────────────────────────────╯

# Default URL:
http://localhost:54323

# Default URL:
postgresql://postgres:postgres@localhost:54322/postgres

psql 'postgresql://postgres:postgres@localhost:54322/postgres'

# Default URL:
http://localhost:54321

curl 'http://localhost:54321/rest/v1/' \
    -H "apikey: sb_publishable_..."

http://localhost:54321/rest/v1/           # REST (PostgREST)
http://localhost:54321/realtime/v1/       # Realtime
http://localhost:54321/storage/v1/        # Storage
http://localhost:54321/auth/v1/           # Auth (GoTrue)

Stop local services [#stopping-local-services]

When you finish working, stop the stack. Stopping doesn't reset your local database:

supabase stop

With the default ports, supabase start runs one local project per machine, because every project's config.toml uses the same ports. To run several local projects or git worktrees at the same time, see Running multiple local projects.

Connect to a hosted project

The stack you started in Run a local Supabase project runs only on your machine. Nothing reaches a hosted project until you sign in to the CLI and link your local directory to one.

For the steps, see Pushing to a remote project. To run deployments from CI, see Configure GitHub Actions.

Change your CLI version

These sections cover the CLI itself rather than your local project.

Use the beta channel [#beta-channel]

Pre-release CLI builds ship from the development branch and are versioned X.Y.Z-beta.N. Use the npm beta dist-tag, or install supabase-beta with Homebrew or Scoop. supabase-beta is a separate package from supabase.

npm install supabase@beta --save-dev

npx supabase@beta --help

brew install supabase/tap/supabase-beta
brew link --overwrite supabase-beta

scoop bucket add supabase https://github.com/supabase/scoop-bucket.git
scoop install supabase-beta

brew install supabase/tap/supabase-beta
brew link --overwrite supabase-beta

Update the Supabase CLI [#updating-the-supabase-cli]

Update the CLI with the same package manager you installed it with. See the CLI releases page for available versions.

npm update supabase --save-dev

npm install supabase@beta --save-dev

brew upgrade supabase

brew upgrade supabase-beta

scoop update supabase

scoop update supabase-beta

brew upgrade supabase

brew upgrade supabase-beta

If you have any Supabase containers running locally, stop them and delete their data volumes before upgrading. Deleting the volumes lets Supabase managed services apply new migrations on a clean local database.

1. Save local schema changes as a migration:

   supabase db diff -f my_schema

2. Dump local data to your seed file:

   supabase db dump --local --data-only > supabase/seed.sql

3. Stop the containers and delete their data volumes:

   supabase stop --no-backup

Telemetry

The Supabase CLI collects telemetry data about general usage. Participating in this program is optional, and you can opt out at any time.

How to opt out

1. Disable telemetry:

   supabase telemetry disable

2. Confirm the current setting:

   supabase telemetry status

To enable telemetry again, run supabase telemetry enable.

You can also opt out using the SUPABASE_TELEMETRY_DISABLED=1 environment variable. The broader DO_NOT_TRACK=1 convention is also respected.

Learn more

• CLI configuration
• CLI reference