Supabase CLI Defaults to Local Now, So CI Jobs May Skip Production

Supabase CLI v3 points database commands at the local stack unless told otherwise, so a CI job that used to push migrations to a hosted project may now succeed without touching it. Supabase flagged the release as a breaking change in its Nov. 4 changelog and advised: “Update your CI before you upgrade, or pin v2” (Supabase changelog, Nov. 4, 2026).

What Changes

Supabase said db push, db pull, db dump, migration list, gen types and storage now target the local stack. A new --remote flag reaches the hosted project. It replaces --linked, --project-ref and --db-url, which are deprecated but still work in v2.

Commands that change a hosted project now ask for confirmation, with No as the default. In CI they fail unless you pass --yes. Piping “y” into a command no longer confirms it. secrets unset also defaults to No and needs --all to clear every secret.

Supabase listed further changes:

• pg-delta becomes the default schema diff engine, so the SQL from db diff and db pull may differ.
• Settings resolve in a fixed order: flag, shell environment, project env files, config file, then default.
• SUPABASE_* variables in CI and env files now override [remotes.<name>] blocks, and config push pushes them.
• The [inbucket] config section is now [local_smtp]. Until you rename it, supabase start fails.
• Deprecated commands, flags, config keys and environment variables are removed. Using one exits with code 1 and prints its replacement.
• The separate supabase-go executable is gone.

The Upgrade Path

Supabase said to move to the latest v2 release first and fix the warnings it prints. Then rename [inbucket], add the needed flags and run supabase stop first if config.toml has no project_id. Run supabase config diff before the first config push on v3.

To stay on v2, pin it with npm install supabase@v2.stable --save-dev, or set version: v2.stable in supabase/setup-cli@v3.

The Take

Without --remote, db push can hit a local stack that the job itself started, and it passes. A green pipeline that never reached production is worse than a red one.

Search every workflow that has an unpinned CLI version and a deploy step for these commands today. Pinning v2 is the cheap fix. The better one is adding --remote and --yes deliberately, so the hosted change is written into the pipeline instead of assumed.