Local Development

Supabase is a flexible platform that lets you decide how you want to build your projects. You can use the Dashboard directly to get up and running quickly, or use a proper local setup. We suggest you work locally and deploy your changes to a linked project on the Supabase Platform.

Doing things directly on the platform via the Dashboard is fine when you're getting started, but it's a good idea to move to a proper local workflow before you get too far. Working locally, generating migrations as you change your tables, and applying those migrations to a linked project on the Platform keeps everything nicely organized as you grow.

Why develop locally?#

The Dashboard provides a wide range of features for setting up your project: creating tables, adding columns, changing existing columns, creating views, setting up RLS policies, and more. Given all of the Dashboard's capabilities, you might question the need to work locally. Here's a few advantages to working this way:

1. Faster Development: Developing locally allows you to work without any network latency or internet disruptions.

2. Easier Collaboration: Developing locally can make it easier to collaborate with others on the same project.

3. Cost-Effective: Supabase provides a generous free tier and gives you two free projects to get started. But what if you need more than two? When you develop locally, you can spin up unlimited local projects and link them with live projects when you're ready to launch.

4. Configuration in code: If you directly change your tables via the Dashboard, none of that gets captured in code. If you follow these local development practices, you'll store all of your table schemas in code.

5. Work offline: Need to work from a train? A plane? An automobile? No problem. Developing your project locally allows you to work offline.

Prerequisites#

Make sure you have these installed on your local machine:

• Docker
• Git
• Supabase CLI

Log in to the Supabase CLI#

1supabase login

Initialize your project#

Create a new folder for your project and start a new git repository:

1# create your project folder
2mkdir your-project
3
4# move into the new folder
5cd your-project
6
7# start a new git repository — important, don't skip this step
8git init

Start Supabase services#

Initialize Supabase to set up the configuration for developing your project locally:

1supabase init

Make sure Docker is running. The start command uses Docker to start the Supabase services. This command may take a while to run if this is the first time using the CLI.

1supabase start

Once all of the Supabase services are running, you'll see output containing your local Supabase credentials. It should look like this, with urls and keys that you'll use in your local project:

Started supabase local development setup.

         API URL: http://localhost:54321
          DB URL: postgresql://postgres:postgres@localhost:54322/postgres
      Studio URL: http://localhost:54323
    Inbucket URL: http://localhost:54324
        anon key: eyJh......
service_role key: eyJh......

You can use the supabase stop command at any time to stop all services.

Access your project's services#

You can now visit your local Dashboard at http://localhost:54323, and access the database directly with any Postgres client via postgresql://postgres:postgres@localhost:54322/postgres.

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

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

Database migrations#

Database changes are managed through "migrations." Database migrations are a common way of tracking changes to your database over time.

For this guide, we'll create a table called employees and see how we can make changes to it.

1supabase migration new create_employees_table

create table
employees (
id bigint primary key generated always as identity,
name text,
email text,
created_at timestamptz default now()
);

1supabase db reset

1supabase migration new add_department_to_employees_table

alter table
if exists public.employees add department text default 'Hooli';

Add sample data#

Now that you are managing your database with migrations scripts, it would be great have some seed data to use every time you reset the database.

For this, you can use the seed script in supabase/seed.sql. This file was automatically created when you ran supabase init) at the beginning.

-- in supabase/seed.sql
insert into
public.employees (name)
values
('Erlich Bachman'),
('Richard Hendricks'),
('Monica Hall');

1supabase db reset

You should now see the employees table, along with your seed data in the Dashboard! All of your database changes are captured in code, and you can reset to a known state at any time, complete with seed data.

Diffing changes#

This workflow is great if you know SQL and are comfortable creating tables and columns. If not, you can still use the Dashboard to create tables and columns, and then use the CLI to diff your changes and create migrations.

Create a new table called cities, with columns id, name and population. To see the corresponding SQL for this, you can use the supabase db diff --schema public command. This will show you the SQL that will be run to create the table and columns. The output of supabase db diff will look something like this:

Diffing schemas: public
Finished supabase db diff on branch main.

create table "public"."cities" (
    "id" bigint primary key generated always as identity,
    "name" text,
    "population" bigint
);

You can then copy this SQL into a new migration file, and run supabase db reset to apply the changes.

The last step is deploying these changes to a live Supabase project.

Deploy your project#

You've been developing your project locally, making changes to your tables via migrations. It's time to deploy your project to the Supabase Platform and start scaling up to millions of users! Head over to Supabase and create a new project to deploy to.

Link your project#

Associate your project with your remote project using supabase link.

1supabase link --project-ref <project-id>
2# You can get <project-id> from your project's dashboard URL: https://app.supabase.com/project/<project-id>
3
4supabase db remote commit
5# Capture any changes that you have made to your remote database before you went through the steps above
6# If you have not made any changes to the remote database, skip this step

supabase/migrations is now populated with a migration in ..._remote_commit.sql. This migration captures any changes required for your local database to match the schema of your remote Supabase project.

Deploy database changes#

Deploy any local database migrations using db push:

supabase db push

Visiting your live project on Supabase, you'll see a new employees table, complete with the department column you added in the second migration above.

Deploy Edge Functions#

If your project uses Edge Functions, you can deploy these using functions deploy:

supabase functions deploy <function_name>

Enabling Local Logging#

Local logs rely on the Supabase Analytics Server. This can be enabled via the CLI configuration, and requires a Google Cloud project and BigQuery access.

Requirements:

1. Google Cloud project number
2. Google Cloud project ID
3. Google Cloud Service Account Key, obtained through Google Cloud IAM dashboard, with BigQuery Admin role assigned to the service account.

Once you have these 3 items, follow these steps:

1. Update your project's config.toml and fill in the following:

[analytics]
enabled = true
gcp_project_number = "123456"
gcp_project_id = "my-project-id"
gcp_jwt_path = "supabase/gcloud.json"

2. Place your service account key (a JSON file) at the corresponding path and ensure that it is correctly named.

3. Start your local stack using supabase start

This will switch the logging drivers and will direct logs to the Analytics server. You will be able to view and query your logs via the Studio Logs Explorer and Logs UI.

Limitations and considerations#

The local development environment is not as feature-complete as the Supabase Platform. We're working towards parity between the hosted platform and the local environment. Here are some of the differences:

• The Functions interface is coming soon.
• You cannot update your project settings in the Dashboard. This must be done using the CLI.