Omit absent bucket file-size limits

When a bucket omits file_size_limit, @supabase/config supplies the schema default (50MiB, see packages/config/src/storage.ts), so this line sends file_size_limit: 52428800 on every create/update. The Go command's per-bucket FileSizeLimit is the zero value unless the TOML key is present, and omitempty then omits it, so common configs like [storage.buckets.images]\npublic = true now unintentionally cap the bucket at 50MiB and update existing buckets to that limit. Recover key presence from the raw document like public and send 0 when absent.

Useful? React with 👍 / 👎.

Thanks — I dug into the Go path on this one and it actually argues for keeping the current behavior, so I'm leaving file_size_limit as-is.

The premise that Go's per-bucket FileSizeLimit stays at the zero value when the TOML key is absent isn't what happens. config.resolve() normalizes every bucket before the seed command sees it (apps/cli-go/pkg/config/config.go:753-756):

if bucket.FileSizeLimit == 0 {
    bucket.FileSizeLimit = c.Storage.FileSizeLimit
}

An omitting bucket inherits the storage-level file_size_limit, which is "50MiB" in every generated config.toml (pkg/config/templates/config.toml:118). So for [storage.buckets.images] + public = true, UpsertBuckets sends file_size_limit: 52428800 (pkg/storage/batch.go:38,49) — the omitempty only fires when both the bucket and storage limits are 0. That matches what the TS code emits today; presence-detecting and omitting file_size_limit would actually diverge from Go (we'd send no limit where Go sends 50MiB). public is genuinely different — it's a *bool with no resolve-time fallback, which is why only that field gets the raw-document presence check.

One real but separate gap I noticed while checking: TS sources the 50MiB from the per-bucket schema default (packages/config/src/storage.ts:43) rather than inheriting the storage-level file_size_limit the way Go's resolve() does. Identical for the default 50MiB case, but it would diverge if someone sets a custom [storage] file_size_limit and omits it on a bucket. I'll track that as its own follow-up. Leaving this thread open for visibility.

Sniff object content types before upload

For uploaded seed files whose extension is missing or not in this table, this falls back to application/octet-stream even when Go would sniff the first 512 bytes with http.DetectContentType (for example, an extensionless PNG is uploaded as image/png). Storage persists the supplied Content-Type, so these objects get different metadata and client behavior after the port; match Go by sniffing the file contents and only using extension lookup for generic text/plain.

Useful? React with 👍 / 👎.

Valid parity observation, escalating as a follow-up rather than fixing here. Go derives content type via http.DetectContentType (sniffing the first 512 bytes) with a mime.TypeByExtension override only for generic text/plain (pkg/storage/objects.go). The TS port deliberately uses an extension-only lookup (documented in buckets.upload.ts as a parity approximation) — matching Go requires porting Go's DetectContentType sniffing algorithm, which is a non-trivial, self-contained piece. Worth doing for strict metadata parity, but tracking separately.

Read piped confirmations before defaulting

When stdin is non-interactive but contains an answer, such as printf 'n\n' | supabase seed buckets for an existing bucket, output.promptConfirm raises NonInteractiveError and this catch immediately returns the default true, so the bucket is overwritten despite the piped n. Go's Console.PromptYesNo still reads non-TTY stdin with a short timeout and parses y/n before falling back to the default, so this path needs to read stdin rather than treating all non-TTY runs as silent defaults.

Useful? React with 👍 / 👎.

Real parity gap, but it lives in the shared legacy prompt infrastructure, not this command. Go's Console.PromptYesNo reads non-TTY stdin with a short timeout and parses y/n before falling back to the default; the TS promptConfirm/NonInteractiveError path treats every non-TTY run as "use the default". Fixing it correctly means changing the shared prompt service (it affects every legacy confirmation prompt, not just seed), so escalating it as a cross-cutting follow-up rather than special-casing seed.

Honor auth.signing_keys_path for generated keys

When auth.signing_keys_path is set and auth.service_role_key is omitted or empty, Go validates/loads that file during config load and generateJWT signs the service-role token with the first JWK; if the file is missing it fails before seeding. This fallback always creates an HS256 token from jwt_secret/the default secret, so asymmetric local stacks can reject the Storage request, and missing signing-key files are ignored while buckets may already be mutated.

Useful? React with 👍 / 👎.

Valid for asymmetric local stacks, escalating as a follow-up. When auth.signing_keys_path is set and service_role_key is empty, Go loads the JWK file at config-load and signs the service-role token with the first key (failing if the file is missing); the TS port always HS256-signs from jwt_secret/the default secret. Matching this needs JWK loading + asymmetric signing support in @supabase/stack (today generateJwt is HS256-only), so it's a larger cross-package change for an uncommon local setup — tracking separately.

Load Go's env-specific dotenv files

Fresh evidence beyond the earlier env-key fix is that this goes through @supabase/config's environment loader, which only reads supabase/.env and .env.local, while Go's loadNestedEnv also loads .env.${SUPABASE_ENV}.local and .env.${SUPABASE_ENV} (defaulting to development) from supabase/ and parent dirs. If auth.service_role_key = "env(SERVICE_ROLE_KEY)" is supplied by supabase/.env.development, Go resolves it before building the Storage client, but this leaves the literal env(...) and sends an invalid apikey.

Useful? React with 👍 / 👎.

Real gap, but it belongs in @supabase/config's environment loader, not this command. Go's loadNestedEnv also loads .env.${SUPABASE_ENV}.local and .env.${SUPABASE_ENV} (default development) from supabase/ and parent dirs, whereas @supabase/config currently reads only .env/.env.local. Since that loader is shared by every config-consuming command, escalating it as a cross-cutting @supabase/config follow-up rather than working around it in seed.

Read the legacy TOML config, not config.json

loadProjectConfig prefers supabase/config.json whenever it exists and may ignore supabase/config.toml, but Go's seed path always loads utils.ConfigPath (supabase/config.toml). In a repo that has a next/experimental JSON config alongside the legacy TOML, seed buckets will now create/update buckets from the JSON file instead of the TOML file that Go users expect; load supabase/config.toml explicitly for this legacy command.

Useful? React with 👍 / 👎.

Real gap in @supabase/config, escalating. loadProjectConfig prefers supabase/config.json when present, but Go's legacy commands always load supabase/config.toml (utils.ConfigPath). The right fix is in the shared loader (or a legacy-specific TOML-only load path) since it affects every legacy command that reads config, not just seed — so tracking it as a cross-cutting follow-up rather than a seed-local workaround.

Validate remotes metadata on local seed runs

Even without --linked, Go's config load scans every [remotes.*] block and rejects duplicate project_ids or malformed remote refs before the Storage client is created. Because this load omits a projectRef, @supabase/config skips the duplicate-remote guard and its remote schema only requires a string, so supabase seed buckets can mutate local buckets from a config that Go would reject up front.

Useful? React with 👍 / 👎.

Accurate on both counts — but this is a @supabase/config gap, not something seed buckets should fix locally, so escalating it as a cross-cutting follow-up.

Go runs two remote validations on every config.Load, independent of any ref:

• duplicate project_id across all [remotes.*] — config.go:503-518
• remote ref-format ^[a-z]{20}$ — config.go:832-836 (Validate, from Load at config.go:717)

On the TS side, @supabase/config has the duplicate guard (io.ts:128-166) but only runs it when a projectRef is supplied (io.ts:355), so a local loadProjectConfig(workdir) skips it; and remoteProjectId is bare Schema.String (base.ts:22-26) with no ^[a-z]{20}$ enforcement. Since every local-config command (db, gen, functions, start, …) shares this divergence, the right fix is in @supabase/config — run the duplicate scan unconditionally and add the ref-format check with Go's exact message — not a seed-local wart. Filing it as a separate config-package parity item; leaving this thread open for visibility. Shout if you'd rather block this PR on it.

Reject unsupported db versions before seeding

When the config contains a Go-invalid database setting such as db.major_version = 12, @supabase/config only decodes the number and this handler proceeds to Storage mutations. The Go seed path runs ParseDatabaseConfig before buckets.Run, and Config.Validate rejects Postgres 12 before NewStorageAPI, so this port can create/update buckets from a config the legacy command would fail up front; run the same db major-version validation before building the gateway.

Useful? React with 👍 / 👎.

Accurate parity observation, but escalating rather than fixing seed-locally — this is the same class as the remotes-validation thread above: Go's Config.Validate rejects an unsupported db.major_version (e.g. 12) at config-load (before NewStorageAPI), and @supabase/config only schema-decodes the number without that validation.

db.major_version is unrelated to storage seeding, so a seed-local check would be a wart — the fix belongs in @supabase/config (port Go's Config.Validate db-version check so every config-loading command inherits it). Filing it with the other cross-cutting @supabase/config validation gaps (remotes duplicate/format, TLS pairing, AutomaticEnv); leaving this thread open for visibility. Shout if you'd rather block this PR on it.

Validate TLS config before linked seeding

Fresh evidence beyond the earlier TLS-validation thread is that this guard still restricts api.tls validation to local runs. Go reaches Config.Validate from ParseDatabaseConfig before NewStorageAPI for both local and --linked (apps/cli-go/pkg/config/config.go:845-861), so with supabase seed buckets --linked and a config such as [api.tls] enabled = true with a missing/unreadable cert/key, this path skips the config-load error and can create/update remote buckets from a config the Go command rejects up front.

Useful? React with 👍 / 👎.

Accurate parity observation — escalating rather than fixing seed-locally, because this is whole-config validation that Go runs in config.Load/Config.Validate for every command (not a storage concern), and the right home is @supabase/config.

Go reaches Config.Validate (config.go:845-861) for both local and --linked before NewStorageAPI, so a bad [api.tls] cert/key pair should also fail on --linked. The seed handler only validates it on the local path today (where it also needs the CA). This belongs with the rest of Go's Config.Validate in @supabase/config so it runs target-independently for all commands. Tracking in the consolidated config-Validate backlog; leaving open.

Reject short JWT secrets on linked runs

When --linked is used with an invalid local auth config such as auth.jwt_secret = "short", Go still runs Auth.generateAPIKeys during config.Load (apps/cli-go/pkg/config/apikeys.go:43-48) and aborts before constructing the remote Storage client. This branch only calls resolveLocalServiceRoleKey on local runs, so the linked path ignores that validation, fetches a remote service key, and can mutate buckets even though the legacy command would fail before any Storage call.

Useful? React with 👍 / 👎.

Accurate parity observation — escalating rather than fixing seed-locally, because this is whole-config validation that Go runs in config.Load/Config.Validate for every command (not a storage concern), and the right home is @supabase/config.

Go runs Auth.generateAPIKeys (apikeys.go:43-48, incl. the < 16 jwt_secret check) during config.Load regardless of target, so --linked with jwt_secret = "short" should fail before any Storage call. The TS port only runs that validation inside the local key derivation. Like the TLS check, this is whole-config validation that should live in @supabase/config (target-independent), not be duplicated per-path in the seed handler. Tracking in the consolidated backlog; leaving open.

Apply SUPABASE_STORAGE_FILE_SIZE_LIMIT before inheriting

This is separate from the auth override fix: Go's config loader uses Viper AutomaticEnv with the SUPABASE_ prefix, so SUPABASE_STORAGE_FILE_SIZE_LIMIT=5MiB overrides [storage].file_size_limit before omitted/zero bucket limits inherit it. Here the inherited value is read only from the decoded TOML/default config, so buckets that omit file_size_limit (or set 0) are created/updated with the wrong limit whenever that supported env override is used.

Useful? React with 👍 / 👎.

Accurate parity observation — escalating rather than fixing seed-locally, because this is whole-config validation that Go runs in config.Load/Config.Validate for every command (not a storage concern), and the right home is @supabase/config.

Same root cause as the auth-env item: Go's loader uses Viper AutomaticEnv + SUPABASE_ prefix (config.go:492-497), so SUPABASE_STORAGE_FILE_SIZE_LIMIT overrides [storage].file_size_limit before the inherit step. @supabase/config only does env(...) interpolation, not AutomaticEnv. A complete fix emulates AutomaticEnv for every config key in @supabase/config (it affects all commands) rather than reading one more env var in the seed handler. Tracking with the AutomaticEnv item in the consolidated backlog; leaving open.

Reject zero API ports before using external_url

After decoding, this path does not run Go's full Config.Validate; with [api] port = 0 and a valid external_url plus configured buckets, Go fails with Missing required field in config: api.port before NewStorageAPI, but this handler later accepts the external_url and can create/update buckets from the invalid config. Validate api.port (while api.enabled is true) before the no-op check or any gateway construction.

Useful? React with 👍 / 👎.

Accurate parity observation — escalating rather than fixing seed-locally, because this is whole-config validation that Go runs in config.Load/Config.Validate for every command (not a storage concern), and the right home is @supabase/config.

Go's Config.Validate rejects api.port = 0 (Missing required field in config: api.port) when api.enabled, before NewStorageAPI; @supabase/config only schema-decodes. This is the same class as the db.major_version and remotes-validation items — whole-config Validate that should be ported into @supabase/config so every command inherits it. Tracking in the consolidated backlog; leaving open.

Decode comma-separated bucket MIME type strings

Go's config decoder includes mapstructure.StringToSliceHookFunc(","), so a bucket config like allowed_mime_types = "image/png,image/jpeg" is valid and reaches UpsertBuckets as a slice. This strict loadProjectConfig path still requires allowed_mime_types to be an array, so the native command rejects a Go-supported seed config before doing any work; accept the string form and split it in the storage schema.

Useful? React with 👍 / 👎.

Accurate, but escalating rather than fixing seed-locally — this is a @supabase/config decode-behavior gap, not a seed concern. Go's config decoder installs mapstructure.StringToSliceHookFunc(","), so allowed_mime_types = "image/png,image/jpeg" is split into a slice for every string-slice config field, across every command. @supabase/config models it as a strict array. The right fix is to add the comma-split decode hook in the config package (so all commands accept the Go-supported string form), not to special-case the seed schema. Tracking with the other @supabase/config parity items; leaving open.

Resolve TLS cert paths like Go before reading

When api.tls.cert_path or key_path is absolute on a local TLS seed, Go still rewrites it with path.Join(SupabaseDirPath, value) during config resolve (apps/cli-go/pkg/config/config.go:795-800), so /tmp/kong.crt is read as supabase/tmp/kong.crt and a missing file aborts before Storage calls. This branch reads the absolute path directly, so a config the legacy command rejects can proceed to create/update buckets; apply the same Supabase-dir join for TLS paths before validation.

Useful? React with 👍 / 👎.

Escalating — this is Go config-resolve path behavior that belongs in @supabase/config. Go rewrites api.tls.cert_path/key_path with filepath.Join(SupabaseDirPath, value) during config resolve (config.go:795-800), so even an absolute /tmp/kong.crt is read relative to supabase/ and a missing file aborts at config-load. The seed handler reads cert_path directly (with an isAbsolute shortcut) because @supabase/config doesn't resolve/read TLS cert content at all yet — the same gap behind the existing TODO in validateLocalKongTls. The faithful fix is to port Go's cert-path resolve (and the cert/key validation) into @supabase/config's load path, so this isn't reimplemented per-command. Tracking with the config-Validate/resolve backlog; leaving open.

Do not descend into a root symlinked directory

When a bucket's objects_path itself is a symlink to a directory, Go's fs.WalkDir visits that root as a symlink and isUploadableEntry skips it as non-regular, so none of the target directory's files are uploaded. This uses stat on the root and then descends when the target is a directory, which can upload an entire linked directory tree that the legacy command would skip.

Useful? React with 👍 / 👎.

I traced this against Go and the current behavior is actually correct — Go does follow a symlinked objects_path root and uploads the target directory's files, so I'm leaving the code as-is (and adding a test to lock it in, d4532c6b).

io/fs.WalkDir is documented to follow a symlinked root: "WalkDir does not follow symbolic links found in directories, but if root itself is a symbolic link, its target will be walked" (io/fs/walk.go). Mechanically it does info := Stat(fsys, root) and builds the root DirEntry from that; fs.Stat falls back to Open(name).Stat() for a non-StatFS (io/fs/stat.go:20-31), and the CLI's rootFS implements only Open (internal/utils/config.go:197-207) → afero.OsFs.Open → os.Open, which follows symlinks. So the root DirEntry is a directory, WalkDir descends, and the target's files upload; isUploadableEntry's symlink branch only ever runs for nested entries (from ReadDir/lstat).

The TS collectFiles mirrors this exactly — fs.stat(absRoot) follows the root symlink, sees a directory, and descends, while nested symlinked dirs are still skipped via the readLink no-follow detector. I added an integration test asserting a symlinked objects_path uploads its target's files. So this is parity-correct as written; leaving the thread open in case you'd like to weigh in.

Validate vector list fields that Go decodes

When ListVectorBuckets returns an entry with a malformed creationTime (for example a string), Go's fetcher.ParseJSON[ListVectorBucketsResponse] fails to unmarshal the uint64 field before any vector create/prune calls. This decoder only checks vectorBucketName, so it can continue with creates or deletes after a list response the legacy command rejects; validate the full Go response shape even for fields not otherwise used.

Useful? React with 👍 / 👎.

Leaving this as-is — it's a technically-real but behaviorally-irrelevant divergence I don't think is worth reproducing. Go's ParseJSON[ListVectorBucketsResponse] would indeed fail to unmarshal a malformed creationTime (string into uint64), but seed buckets never reads creationTime — only vectorBucketName drives any create/prune decision. The only way to hit this is the local Storage server returning a malformed creationTime in an otherwise-valid list (a server bug, not a user config), and the sole observable effect would be erroring slightly earlier on a response we'd otherwise process identically.

Reproducing full struct-shape validation for unused numeric fields is gold-plating with no behavioral parity benefit, so I'm intentionally scoping the strict decode to the fields that affect behavior (the same call I flagged when adding it). Happy to revisit if you have a concrete case where it matters; leaving open for visibility.

Expose seed target flags on the parent command

Go registers --linked and --local as persistent flags on seed (apps/cli-go/cmd/seed.go:29-32), so existing invocations like supabase seed --linked buckets are valid. Here the TS seed parent has no flag config and these flags are attached only to the buckets leaf, so the parent-position form has no flag to consume before the handler runs; only supabase seed buckets --linked is supported. Move or share these flags at the seed command level to preserve the Go command surface.

Useful? React with 👍 / 👎.

Accurate — Go registers --linked/--local as persistent flags on the seed parent (cmd/seed.go:29-32), so supabase seed --linked buckets is valid, whereas the TS attaches them to the buckets leaf, supporting only supabase seed buckets --linked. Escalating rather than fixing inline, because the faithful fix is a command/flag-wiring change with parser-level behavior I can't cheaply verify in the loop: declare the two flags via Command.withGlobalFlags([...]) on the seed group (the Effect equivalent of Go's PersistentFlags — position-independent + scoped to seed), then refactor the buckets handler to read them as global-flag tokens instead of the leaf Command.make("buckets", config) arg, and rethread them into withLegacyCommandInstrumentation({ flags }) for telemetry. (The mutual-exclusivity check already scans argv via legacySeedChangedTargetFlags, so it's position-independent today.) Tracking as a CLI-surface follow-up; leaving open.

Do not skip linked runs when config is missing

When --linked is used from a workdir without supabase/config.toml/config.json, loadProjectConfig returns null and this exits before fetching the service key or calling Storage. The Go path still loads embedded defaults when the config file is absent; because the project ref is non-empty, buckets.Run does not short-circuit and NewStorageAPI/ListBuckets runs, surfacing missing-token or Storage errors. This native path can therefore report success for a linked invocation the legacy command would fail or at least contact the remote project for.

Useful? React with 👍 / 👎.

Accurate, and escalating — this is @supabase/config Load behavior, not seed-specific. Go's config.Load falls back to embedded defaults when no config.toml exists, so seed buckets --linked with a non-empty ref still builds the Storage client and runs ListBuckets (surfacing auth/Storage errors) rather than short-circuiting. @supabase/config's loadProjectConfig returns null when no config file is present, so the handler exits early. Reproducing Go's "always have a config (defaults)" belongs in the config package (it affects every command that loads config without a file), alongside the other config.Load/Validate parity items I've flagged. Tracking there; leaving open.

Validate analytics bucket list fields

Fresh evidence beyond the earlier list-decoder thread is that the analytics decoder still only checks name. If /storage/v1/iceberg/bucket returns an entry with malformed id, created_at, or updated_at (for example a numeric id), Go's fetcher.ParseJSON[[]AnalyticsBucketResponse] fails before any analytics create/prune calls, but this path accepts the response and can continue to delete or create analytics buckets after a response the legacy command rejects.

Useful? React with 👍 / 👎.

Leaving this as-is for the same reason as the vector creationTime thread — it's a technically-real but behaviorally-irrelevant divergence on unused fields. seed buckets reads only name from the analytics list (to compute create/prune); id/created_at/updated_at are never used. Go's ParseJSON[[]AnalyticsBucketResponse] would indeed reject a malformed id, but the only trigger is the local Storage server returning a malformed-but-otherwise-valid list (a server bug, not user config), and the sole effect would be erroring slightly earlier on a response we'd otherwise process identically.

I strict-decode the fields that drive behavior (name here; name+id for buckets, where id is used as the update target; vectorBucketName for vector) and intentionally don't gold-plate unused fields. Happy to revisit with a concrete case where it matters; leaving open for visibility.

Use Go-compatible local service-role JWTs

When a local config omits auth.service_role_key or sets it to an empty string, Go generates the deterministic default service-role key with issuer supabase-demo and the fixed expiry asserted in apps/cli-go/pkg/config/config_test.go; the legacy start command is still wrapped, so local Kong is commonly configured with that exact key. This call uses @supabase/stack's generator instead, which includes the current time and issuer supabase, so the apikey sent by seed buckets can differ from the key the running Go-started local gateway accepts and fail with auth errors before any seeding.

Useful? React with 👍 / 👎.