Existing issues
Affected area
Local development
Problem to solve
The CLI has no direct command to check whether it can load and validate supabase/config.toml without starting services or changing local or remote project state.
Today, config errors surface as a side effect of commands such as supabase start, supabase db reset --local, or supabase config push. That makes a simple pre-commit or CI check harder than it needs to be.
This is also useful for AI coding agents. After changing config.toml, an agent should be able to run one bounded command, read its exit status and diagnostic, fix the problem, and retry. It should not need Docker, a login, or a remote project just to check the config.
The scope should stay narrow: this command would confirm that the running CLI accepts the project configuration. It would not claim that the database, migrations, services, the whole project, or the hosted Branching parser are healthy.
Proposed solution
Add a new command: supabase config validate.
The command would:
- require
supabase/config.toml, with a supabase init hint when it is missing;
- use the CLI's existing config loading and validation rules rather than introduce a separate validation contract;
- preserve the CLI's existing warnings and error diagnostics;
- print a short success message and exit 0 when the config is valid;
- exit non-zero when the config is invalid;
- require no Docker, running local services, login, or remote project mutation.
Alternatives considered
supabase start performs real work and requires Docker.
supabase config push requires authentication and a remote project, and can change remote configuration.
- JSON Schema is useful for editor feedback, but it is not the same as running the CLI's config loader with its environment resolution and runtime validation rules.
- A custom CI script would create another validation contract that could drift from the CLI.
Additional context
I searched the current open issues and pull requests, all closed issue titles and bodies, and repository history and did not find an existing request for this command.
The closest prior work has different scope: #1412 requested warnings for unknown config options, which were later implemented; #3033 requested JSON Schema for editor support; merged PR #5840 validates config only on the db reset --local path; and #5801 is a hosted Branching parser compatibility bug. None provides a standalone validation command with a reusable exit status.
Would you prefer a base-config-only first version, or should it also validate a selected [remotes.*] override through --project-ref?
I'd be happy to contribute this after maintainer triage if the issue is labeled open-for-contribution.
Existing issues
Affected area
Local development
Problem to solve
The CLI has no direct command to check whether it can load and validate
supabase/config.tomlwithout starting services or changing local or remote project state.Today, config errors surface as a side effect of commands such as
supabase start,supabase db reset --local, orsupabase config push. That makes a simple pre-commit or CI check harder than it needs to be.This is also useful for AI coding agents. After changing
config.toml, an agent should be able to run one bounded command, read its exit status and diagnostic, fix the problem, and retry. It should not need Docker, a login, or a remote project just to check the config.The scope should stay narrow: this command would confirm that the running CLI accepts the project configuration. It would not claim that the database, migrations, services, the whole project, or the hosted Branching parser are healthy.
Proposed solution
Add a new command:
supabase config validate.The command would:
supabase/config.toml, with asupabase inithint when it is missing;Alternatives considered
supabase startperforms real work and requires Docker.supabase config pushrequires authentication and a remote project, and can change remote configuration.Additional context
I searched the current open issues and pull requests, all closed issue titles and bodies, and repository history and did not find an existing request for this command.
The closest prior work has different scope: #1412 requested warnings for unknown config options, which were later implemented; #3033 requested JSON Schema for editor support; merged PR #5840 validates config only on the
db reset --localpath; and #5801 is a hosted Branching parser compatibility bug. None provides a standalone validation command with a reusable exit status.Would you prefer a base-config-only first version, or should it also validate a selected
[remotes.*]override through--project-ref?I'd be happy to contribute this after maintainer triage if the issue is labeled
open-for-contribution.