When running a production app on Supabase, the standard recommendation is to use two
separate projects (e.g. my-app-staging and my-app-prod) to maintain isolated
environments. This works, but Supabase currently provides no native tooling to keep
them in sync. Every schema migration, edge function deploy, auth config change, or
RLS policy update has to be manually applied to both projects.
The existing Branching feature doesn't solve this because:
Database replication also doesn't fit. We don't want data to flow between environments, only schema and configuration.
A lightweight "project sync" mechanism for persistent multi-environment setups:
supabase db push --target-project <ref>
that applies pending migrations to a second project (already partially possible,
but needs a cleaner workflow)supabase functions deploy <name> --projects staging,prod
or a config in supabase/config.toml that maps functions to multiple target projectsEduardo is requesting a feature for syncing schema, edge functions, and auth configurations between staging and production projects in Supabase. The current branching feature is not suitable due to its ephemeral nature and cost. The user suggests CLI commands for syncing configurations across projects to avoid manual duplication, which is error-prone.
supabase secrets push --project <ref> targeting multiple projectsThis is especially painful for teams not using Vercel (where Branching has better integration). Example stack where this gap hurts:
staging branch → staging env,
main → prod)The Amplify + EC2 + Supabase combo is common outside the JS/Vercel ecosystem, and those teams have no native path to environment parity today.
Manually running migrations against each project via CLI and maintaining a deploy checklist:
supabase db push per projectsupabase functions deploy per projectThis is error-prone and the most common source of "works in staging, broken in prod" bugs.