Describe the bug
A fresh self-host fails during supabase start (or bun run setup:env) while applying migrations:
Applying migration 0008_preview-img-storage.sql...
Stopping containers...
ERROR: Direct deletion from storage tables is not allowed. Use the Storage API instead. (SQLSTATE 42501)
At statement: 0
delete from storage.objects where bucket_id = 'preview_images'
0008_preview-img-storage.sql and 0012_file-transfer-bucket.sql both start with direct deletes against storage.objects / storage.buckets. Recent Supabase versions reject direct writes to storage tables, so every fresh clone on a current CLI dies at migration 0008 and the backend never comes up.
Steps to reproduce
- Fresh clone on a machine with a current Supabase CLI (hit with 2.75.0; repo pins ^2.45.5, where it still passes)
cd apps/backend && supabase start
- Migration 0008 fails with SQLSTATE 42501, containers stop
Expected behavior
Fresh self-host completes supabase start and applies all migrations.
Suggested fix
On a fresh database the deletes are no-ops, so the delete+insert pair can become an upsert with identical results:
insert into storage.buckets (id, name, public)
values ('preview_images', 'preview_images', true)
on conflict (id) do update set public = excluded.public;
Same for file_transfer in 0012. Verified locally — supabase start completes and both buckets exist with the right visibility. One behavior note for review: the old code also wiped existing objects in those buckets on re-run; the upsert preserves them.
Happy to open a PR — have the change ready.
Describe the bug
A fresh self-host fails during
supabase start(orbun run setup:env) while applying migrations:0008_preview-img-storage.sqland0012_file-transfer-bucket.sqlboth start with direct deletes againststorage.objects/storage.buckets. Recent Supabase versions reject direct writes to storage tables, so every fresh clone on a current CLI dies at migration 0008 and the backend never comes up.Steps to reproduce
cd apps/backend && supabase startExpected behavior
Fresh self-host completes
supabase startand applies all migrations.Suggested fix
On a fresh database the deletes are no-ops, so the delete+insert pair can become an upsert with identical results:
Same for
file_transferin 0012. Verified locally —supabase startcompletes and both buckets exist with the right visibility. One behavior note for review: the old code also wiped existing objects in those buckets on re-run; the upsert preserves them.Happy to open a PR — have the change ready.