supabase-local-dev-loop
Configures a local Supabase stack using Docker and the CLI to enable fast iteration, migration testing, and schema management.
Install
mkdir -p .claude/skills/supabase-local-dev-loop && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/8966" && unzip -o skill.zip -d .claude/skills/supabase-local-dev-loop && rm skill.zipInstalls to .claude/skills/supabase-local-dev-loop
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Configure Supabase local development with the CLI, Docker, and migrationKey capabilities
- →Initialize local Supabase stack with Docker
- →Manage version-controlled SQL migration files
- →Seed development data automatically
- →Capture schema changes via diff-based migrations
- →Test Edge Functions with hot reload
How it works
It uses the Supabase CLI and Docker to run a local instance of the platform, allowing developers to iterate on schema changes and migrations before deployment.
Inputs & outputs
When to use supabase-local-dev-loop
- →Initializing a new local Supabase project
- →Running database migrations locally
- →Seeding development data
- →Testing schema changes before deployment
About this skill
Supabase Local Dev Loop
Overview
Run the full Supabase stack locally — Postgres, Auth, Storage, Realtime, Edge Functions, and Studio — using Docker and the Supabase CLI. Local development mirrors production APIs exactly, enabling offline work, fast iteration, and repeatable migration workflows. Schema changes flow through supabase db diff to generate migrations, and supabase db reset replays them cleanly.
Prerequisites
- Docker Desktop installed and running (required for all local services)
- Node.js 18+ (for
npx supabasecommands) - No global install needed — all commands use
npx supabase
Instructions
Step 1: Initialize Project and Start Local Stack
# Initialize Supabase in your project root
npx supabase init
This creates a supabase/ directory:
supabase/
├── config.toml # Local stack configuration (ports, auth settings)
├── migrations/ # SQL migration files (version-controlled)
└── seed.sql # Seed data (runs after migrations on db reset)
Start the local stack (first run pulls Docker images — takes a few minutes):
npx supabase start
The CLI prints all local endpoints and keys:
API URL: http://localhost:54321
GraphQL URL: http://localhost:54321/graphql/v1
S3 Storage URL: http://localhost:54321/storage/v1/s3
DB URL: postgresql://postgres:postgres@localhost:54322/postgres
Studio URL: http://localhost:54323
Inbucket URL: http://localhost:54324
anon key: eyJhbGciOiJI...
service_role key: eyJhbGciOiJI...
Create .env.local from these values (git-ignored):
# .env.local
SUPABASE_URL=http://localhost:54321
SUPABASE_ANON_KEY=<anon-key-from-supabase-start>
SUPABASE_SERVICE_ROLE_KEY=<service-role-key-from-supabase-start>
DATABASE_URL=postgresql://postgres:postgres@localhost:54322/postgres
Verify the stack is running:
npx supabase status
Step 2: Create Migrations and Seed Data
Create a migration file with a descriptive name:
npx supabase migration new create_profiles
# Creates: supabase/migrations/<timestamp>_create_profiles.sql
Write the migration SQL:
-- supabase/migrations/<timestamp>_create_profiles.sql
create table public.profiles (
id uuid references auth.users(id) primary key,
username text unique not null,
avatar_url text,
created_at timestamptz default now(),
updated_at timestamptz default now()
);
-- Always enable RLS on public tables
alter table public.profiles enable row level security;
create policy "Public profiles are viewable by everyone"
on public.profiles for select
using (true);
create policy "Users can update own profile"
on public.profiles for update
using (auth.uid() = id);
-- Auto-create profile on signup via trigger
create or replace function public.handle_new_user()
returns trigger as $$
begin
insert into public.profiles (id, username)
values (new.id, new.raw_user_meta_data->>'username');
return new;
end;
$$ language plpgsql security definer;
create trigger on_auth_user_created
after insert on auth.users
for each row execute procedure public.handle_new_user();
Add seed data for local development:
-- supabase/seed.sql (runs automatically after migrations on db reset)
insert into auth.users (id, email, raw_user_meta_data)
values
('a1b2c3d4-e5f6-7890-abcd-ef1234567890', '[email protected]',
'{"username": "alice"}'),
('b2c3d4e5-f6a7-8901-bcde-f12345678901', '[email protected]',
'{"username": "bob"}');
Apply migrations and seed data in one command:
npx supabase db reset
# Drops the database, replays all migrations, runs seed.sql
Step 3: Iterate with Diff-Based Migrations
The core iteration loop: make changes in Studio, diff them into migration files, then verify with a clean reset.
Open Studio at http://localhost:54323 and make schema changes interactively (add columns, create tables, modify RLS policies). Then capture those changes as a migration:
# Generate a migration from the diff between migrations and current DB state
npx supabase db diff -f add_bio_to_profiles
# Review the generated file
cat supabase/migrations/*_add_bio_to_profiles.sql
The generated migration captures exactly what changed:
-- Auto-generated by supabase db diff
alter table public.profiles add column bio text;
Verify the full migration chain replays cleanly:
npx supabase db reset
# Success = all migrations + seed apply without errors
Push verified migrations to a remote Supabase project:
# Link to remote project first (one-time)
npx supabase link --project-ref <your-project-ref>
# Push migrations to remote
npx supabase db push
Daily workflow summary:
# Start of day
npx supabase start
# After schema changes in Studio
npx supabase db diff -f descriptive_name
npx supabase db reset # Verify clean replay
# Before committing
npx supabase db reset # Final verification
npm test # Run tests against local instance
# End of day
npx supabase stop
Output
- Local Supabase stack running all services via Docker (Postgres, Auth, Storage, Realtime, Studio)
- Version-controlled migration files in
supabase/migrations/ - Seed data for repeatable local state
- Diff-based migration workflow for safe schema iteration
.env.localwith local connection credentials
Error Handling
| Error | Cause | Solution |
|---|---|---|
Cannot connect to Docker daemon | Docker not running | Start Docker Desktop, then retry npx supabase start |
Port 54321 already in use | Previous instance still running | Run npx supabase stop then npx supabase start |
supabase db reset fails | Syntax error in migration SQL | Check the failing migration file, fix SQL, re-run reset |
Permission denied on start | Docker socket permissions | Add user to docker group: sudo usermod -aG docker $USER |
supabase db diff empty | No schema changes detected | Verify changes were made in the local DB, not just Studio UI cache |
relation "auth.users" does not exist | Running migration outside Supabase | Auth schema only exists in the Supabase-managed Postgres instance |
Examples
Connect from Application Code
import { createClient } from '@supabase/supabase-js'
const supabase = createClient(
process.env.SUPABASE_URL!, // http://localhost:54321 locally
process.env.SUPABASE_ANON_KEY! // Local anon key from supabase start
)
// Fetch profiles — works identically in local and production
const { data, error } = await supabase
.from('profiles')
.select('username, avatar_url')
.limit(10)
Test Against Local Instance with Vitest
import { createClient } from '@supabase/supabase-js'
import { describe, it, expect, beforeAll } from 'vitest'
const supabase = createClient(
'http://localhost:54321',
'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...' // Local anon key
)
describe('profiles', () => {
beforeAll(async () => {
// Seed data is already loaded via supabase db reset
})
it('fetches public profiles', async () => {
const { data, error } = await supabase
.from('profiles')
.select('username')
.limit(1)
expect(error).toBeNull()
expect(data).toHaveLength(1)
expect(data![0].username).toBeDefined()
})
it('enforces RLS on update', async () => {
// Anon users cannot update profiles (no auth.uid())
const { error } = await supabase
.from('profiles')
.update({ username: 'hacker' })
.eq('username', 'alice')
expect(error).not.toBeNull()
})
})
Edge Function Local Development
# Create and serve an Edge Function with hot reload
npx supabase functions new hello-world
npx supabase functions serve --env-file .env.local
# Test it
curl -X POST http://localhost:54321/functions/v1/hello-world \
-H "Authorization: Bearer $SUPABASE_ANON_KEY" \
-H "Content-Type: application/json" \
-d '{"name": "World"}'
Resources
- Local Development Overview
- Supabase CLI Reference
- Database Migrations
- Edge Functions Quickstart
- Row Level Security
Next Steps
Proceed to supabase-sdk-patterns for production-ready client initialization, typed queries, and real-time subscriptions.
When not to use it
- →When Docker is unavailable on the host machine
- →When testing requires production-only cloud features
Prerequisites
Limitations
- →First run requires pulling Docker images
- →Local state is reset during db reset commands
How it compares
This workflow provides a local, offline-capable environment that mirrors production APIs exactly, unlike manual cloud-based testing.
Compared to similar skills
supabase-local-dev-loop side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| supabase-local-dev-loop (this skill) | 0 | 26d | Caution | Beginner |
| test-with-postgres | 1 | 2mo | Review | Intermediate |
| drizzle-orm | 32 | 2mo | No flags | Intermediate |
| database-design | 6 | 6mo | Review | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by jeremylongshore
View all by jeremylongshore →You might also like
test-with-postgres
storj
Run unit tests that require PostgreSQL. Use this skill when the user wants to run tests with PostgreSQL database backend. Automatically handles checking for and configuring a PostgreSQL Docker container.
drizzle-orm
EpicenterHQ
Drizzle ORM patterns for type branding and custom types. Use when working with Drizzle column definitions, branded types, or custom type conversions.
database-design
davila7
Database design principles and decision-making. Schema design, indexing strategy, ORM selection, serverless databases.
database-schema-designer
davila7
Design robust, scalable database schemas for SQL and NoSQL databases. Provides normalization guidelines, indexing strategies, migration patterns, constraint design, and performance optimization. Ensures data integrity, query performance, and maintainable data models.
database-migrations-sql-migrations
sickn33
SQL database migrations with zero-downtime strategies for PostgreSQL, MySQL, SQL Server
postgresql-syntax-reference
pgschema
Consult PostgreSQL's parser and grammar (gram.y) to understand SQL syntax, DDL statement structure, and parsing rules when implementing pgschema features