feat(cli): add --no-seed flag to supabase start

[MuzzaiyyanHussain]

Adds a --no-seed flag to supabase start to skip storage bucket seeding during startup.
This allows faster restarts and avoids unnecessary seeding when it’s not needed.
Default behavior remains unchanged when the flag is not used.

[coveralls]

Pull Request Test Coverage Report for Build 20892845078

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 5 of 12 (41.67%) changed or added relevant lines in 2 files are covered.
• 8 unchanged lines in 2 files lost coverage.
• Overall coverage decreased (-0.05%) to 56.126%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
cmd/start.go	0	2	0.0%
internal/start/start.go	5	10	50.0%

Files with Coverage Reduction	New Missed Lines	%
internal/debug/postgres.go	3	66.09%
internal/gen/keys/keys.go	5	12.9%

Totals
Change from base Build 20869614818:	-0.05%
Covered Lines:	6849
Relevant Lines:	12203

---

💛 - Coveralls

[sweatybridge]

Is it not sufficient to use config.toml to turn off seeding?

[db.seed]
enabled = false

[MuzzaiyyanHussain]

Good question.
db.seed.enabled = false only controls SQL/database seeding, but this issue is about storage bucket seeding, which currently runs unconditionally during supabase start.
The --no-seed flag is meant as a one-off CLI override (useful for local dev, CI, or recovery scenarios) without requiring config changes.
Happy to adjust this to reuse config if you prefer, but at the moment config.toml doesn’t cover storage seeding.

[MuzzaiyyanHussain]

Hi @sweatybridge Just to confirm, should storage seeding fully follow db.seed.enabled, and --no-seed act only as a temporary CLI override?

If that works for you, I’ll update the implementation and push a follow-up commit.

[sweatybridge]

Just to confirm, should storage seeding fully follow db.seed.enabled, and --no-seed act only as a temporary CLI override?

Generally I'd avoid adding more flags because it's hard to maintain. But I agree --no-seed is desired in this case for adhoc invocation of supabase start command.

My only suggestion is to reuse the noSeed variable instead of declaring a new one.

And yes, let's have storage seeding follow db.seed.enabled for simplicity. Technically seeding storage objects also means inserting metadata entry into storage.objects table, so it's not wrong to use the same config.

[MuzzaiyyanHussain]

That makes sense

I’ll reuse the existing noSeed variable instead of introducing a new one, and update the logic so storage seeding follows db.seed.enabled, with --no-seed acting as an ad-hoc override for supabase start.

I’ll push a follow-up commit with these changes shortly.

[MuzzaiyyanHussain]

I’ve updated storage seeding to follow db.seed.enabled by default, with --no-seed acting as a CLI override.
Added a test to cover the config-based behavior.
Tests pass and I verified manually with go run . start --no-seed on Windows.