gen types --db-url still requires local supabase start state (fails with "supabase start is not running")

[mikkelam]

Describe the bug

supabase gen types --lang typescript --db-url "postgresql://postgres:postgres@127.0.0.1:54322/postgres" fails with supabase start is not running even though the database is reachable and we intentionally do not use supabase start (containers are managed with Docker Compose). Debug output shows it still resolves local profile/project state (Using profile: supabase) and fails in internal/gen/types/types.go:65.

To Reproduce

1. Run local Postgres with Docker Compose (no supabase start), reachable at 127.0.0.1:54322.
2. Run: (with appropriate db-url)

supabase gen types --lang typescript --db-url "postgresql://postgres:postgres@127.0.0.1:54322/postgres" --debug

3. See error and stack trace:

supabase gen types --lang typescript --db-url "postgresql://postgres:postgres@127.0.0.1:54322/postgres" --debug
open /Users/user/.supabase/profile: no such file or directory
Supabase CLI
Using profile: supabase (supabase.co)
github.com/supabase/cli/internal/utils/misc.go:151 (0x103875c68)
github.com/supabase/cli/internal/utils/misc.go:145 (0x10388030c)
github.com/supabase/cli/internal/gen/types/types.go:65 (0x10388030d)
github.com/supabase/cli/cmd/gen.go:99 (0x104f3adcc)
github.com/spf13/cobra@v1.10.2/command.go:1015 (0x102dc1fd4)
github.com/spf13/cobra@v1.10.2/command.go:1148 (0x102dc2750)
github.com/supabase/cli/cmd/root.go:173 (0x104f497a8)
github.com/supabase/cli/main.go:11 (0x104f4e15c)
internal/runtime/atomic/types.go:194 (0x102c0f168)
runtime/asm_arm64.s:1268 (0x102c4ad14)

supabase start is not running.

Expected behavior

gen types should connect directly to the provided --db-url and generate types without requiring local supabase start state.

System information

• Ticket ID: 3748954abc3e406190420d9f5c015245
• Version of OS: macOS (Apple Silicon)
• Version of CLI: reproduces on 2.90.0 and 2.100.0
• Version of Docker: local Docker daemon via OrbStack
• Versions of services: custom compose stack (Postgres + PostgREST + Storage + imgproxy + Kong)

Additional context

• We do not use Supabase CLI for container lifecycle; only Docker Compose.
• supabase/config.toml present vs removed did not change behavior (A/B tested).
• Related issue: Supabase gen types --db-url Fails Without Docker Desktop #2536 (similar --db-url behavior requiring local stack state).

[avallete]

The error comes from apps/cli-go/internal/gen/types/types.go. When --db-url is provided, we parse it into a pgconn.Config and then run it through utils.IsLocalDatabase, which is just a heuristic on host + port:

func IsLocalDatabase(config pgconn.Config) bool {
    return config.Host == Config.Hostname &&
        (config.Port == Config.Db.Port || config.Port == Config.Db.ShadowPort)
}

So any --db-url pointing at 127.0.0.1:54322 (i.e. anything that looks like a local Supabase DB, even a Postgres the user is running themselves outside supabase start) gets classified as local. Once classified as local, gen types does two things in types.go:

if utils.IsLocalDatabase(dbConfig) {
    if err := utils.AssertSupabaseDbIsRunning(); err != nil {
        return err            // <-- the error reported in this issue
    }
    dbConfig.Host = utils.DbAliases[0]   // "supabase_db_<ref>"
    dbConfig.Port = 5432
} else {
    hostConfig.NetworkMode = network.NetworkHost
}

1. AssertSupabaseDbIsRunning() does a docker inspect supabase_db_<ref> and returns ErrNotRunning if the container isn't there — that's the failure users hit when the stack isn't up.
2. If the assert had passed, we rewrite host/port to the Docker network alias supabase_db_<ref>:5432 so the pg-meta container we spawn can reach Postgres over the project's Docker network.

Why the rewrite exists at all: gen types runs pg-meta as a one-shot Docker container. To reach a DB on the host's localhost:54322 from inside that container you need either (a) the Docker network alias of a running local stack, or (b) network=host on the spawned container. Today the code unconditionally picks (a) whenever the URL "looks local", which silently assumes supabase start is up.

The bug is the classification: --db-url is an explicit user override and shouldn't trigger the local-stack assumption. Fix is to either always take the network=host branch when --db-url is provided (don't rewrite to the alias, don't assert the container), or restrict the IsLocalDatabase path to the --local/--linked callers and treat --db-url as remote-style for transport.

I would lean into using network=host