config diff reports api.enabled = true after config push disables the Data API (pg_pgrst_no_exposed_schemas)
Maintainers usually reply within 1 day
@7ttp is already working on this.
Since Oct 1, 2026.
Assessment
This issue has not been assessed yet.
Description
Describe the bug
After supabase config push turns the Data API off ([api] enabled = false), supabase config diff still reports api.enabled as true on the remote. config diff --exit-code therefore never exits 0 for a project with the Data API disabled, and every later config push re-sends the same db_schema update.
The push itself works: PATCH /v1/projects/{ref}/postgrest with db_schema: "" is accepted, and GET /v1/projects/{ref}/postgrest then returns "db_schema": "". The effective config (GET /v2/projects/{ref}/config), which config diff reads, returns "db_schema": "pg_pgrst_no_exposed_schemas". That value is the platform's "Data API disabled" marker, per the troubleshooting guide "schema pg_pgrst_no_exposed_schemas does not exist".
The api.enabled row in packages/config/src/project-config/registry.ts (v2.117.0, unchanged in v2.119.0) maps it as:
configPath: ["api", "enabled"],
apiPath: apiDbSchemaPath,
transform: (value) => expectString(value, apiDbSchemaPath).length > 0,
So the marker reads as "enabled".
To reproduce
config.tomlwith[api] enabled = false.supabase config push --project-ref <ref> --yes: reportsapi.enabled [update] local: false, remote: trueand updates the API service.supabase config diff --project-ref <ref> --exit-code: still listsapi.enabled(localfalse, remotetrue) and exits non-zero.- Steps 2 and 3 repeat identically on every run.
Expected behavior
db_schema == "pg_pgrst_no_exposed_schemas" (as well as "") maps to api.enabled = false, so the diff is clean after a successful disable, and push does not re-send it.
Versions
- Supabase CLI 2.117.0 (also checked the source of 2.119.0); hosted projects
Related, smaller
config push reports auth.sms.twilio.enabled as unencodable ("cannot turn the active provider off"). Hosted projects start with sms_provider: "twilio" even with phone sign-in off. PATCH /v1/projects/{ref}/config/auth {"sms_provider": null} returns 200 but the value stays "twilio", so a config with no SMS provider can never diff clean. Treating the provider as inactive while external_phone_enabled is false would resolve it.
- Dominant language
- TypeScript
- Stars
- 2.4k
- Forks
- 526
- Avg merge
- 1d 2h
- Merged PRs (30d)
- 323
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from supabase/cli
-
🐛 Bug supabase/cli
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 1 day
-
🐛 Bug supabase/cli
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 1 day
-
📘 Docs supabase/cli
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
🐛 Bug supabase/cli
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
🐛 Bug supabase/cli
Difficulty 4/5 3-5 days Newbie friendliness 55/100
Maintainers usually reply within 1 day
Similar issues
-
enhancement providers-api ui-dashboard
Difficulty 2/5 1-3 hours Newbie friendliness 61/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
external-issue to-triage
Difficulty 1/5 Under an hour Newbie friendliness 90/100
Maintainers usually reply within 1 day
-
needs triage
Difficulty 1/5 Under an hour Newbie friendliness 88/100
homarr-labs/homarr#6976 · 2 comments ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day