Supabase CLI 3.0 flips db push and pull to target local by default
A major CLI release changes which project your commands hit by default, requires confirmation before touching a hosted project, and drops the supabase-go binary.
Supabase CLI v3.0.0 shipped on 2 November, and it changes what your existing scripts actually do. Commands like db push and db pull now default to your local stack instead of a linked hosted project. A single --remote flag replaces --linked, --project-ref and --db-url for targeting a hosted project; the old flags still work but are hidden from help text and print a warning.
Every change to a hosted project now asks for confirmation, and piping y on stdin no longer counts, nor does SUPABASE_YES set in a .env file. Scripts need an explicit --yes flag to run non-interactively. Configuration resolution order also changed: flag, then shell environment, then project env files, then config.toml, so a value you expected from config.toml can now be silently overridden by something already in your shell. Anyone with an [inbucket] section in supabase/config.toml has to rename it to [local_smtp] before upgrading, since v3 refuses to load the old key. The bundled supabase-go binary, plus commands like db remote commit, db branch create and gen keys, are gone entirely.
Why it matters: if you have CI pipelines or local scripts built around the old defaults, this upgrade can silently start running against your local stack instead of your hosted project, or start failing non-interactively because confirmation is now required. Check config.toml for [inbucket] and any CI script that pipes y or sets SUPABASE_YES before you bump the version.
supabase db push --remote --yes