db push: "failed to cache migrations catalog" — pg-delta can't read pgdelta-target-ca.crt inside edge-runtime (ENOENT at /workspace/...)

[buffpesos]

Describe the bug

Every supabase db push (and db dump --linked) against a linked hosted project ends with a noisy warning + double-printed crash from the post-push pg-delta catalog caching step:

Applying migration 20260721130000_xxx.sql...
Warning: failed to cache migrations catalog: error exporting pg-delta catalog: edge-runtime script produced no output:
runtime has escaped from the event loop unexpectedly: event loop error: Error: Failed to read certificate file '/workspace/supabase/.temp/pgdelta/pgdelta-target-ca.crt': ENOENT: no such file or directory, open '/workspace/supabase/.temp/pgdelta/pgdelta-target-ca.crt'
    at getCertValue (file:///var/tmp/sb-compile-edge-runtime/node_modules/localhost/@supabase/pg-delta/1.0.0-alpha.27/dist/core/plan/ssl-config.js:44:27)
    at async parseSslConfig (file:///var/tmp/sb-compile-edge-runtime/node_modules/localhost/@supabase/pg-delta/1.0.0-alpha.27/dist/core/plan/ssl-config.js:62:23)
    at async createManagedPool (file:///var/tmp/sb-compile-edge-runtime/node_modules/localhost/@supabase/pg-delta/1.0.0-alpha.27/dist/core/postgres-config.js:340:23)
    at async file:///var/tmp/sb-compile-edge-runtime/index.ts:10:25
main worker has been destroyed
event loop error: <same trace again>
Finished supabase db push.

The migration itself applies fine (it goes over the CLI's own direct connection before this step) — only the catalog cache fails. But it fires on every push, prints the stack twice, and looks alarming.

Root cause (from reading the CLI source)

The CA bundle is written on the host — after the failing run, supabase/.temp/pgdelta/pgdelta-target-ca.crt exists in the project dir with the embedded staging+prod+snap bundle. The prepare step (PreparePgDeltaPostgresRef in internal/gen/types/pgdelta_conn.go / legacyPreparePgDeltaRef in apps/cli/src/legacy/shared/legacy-pgdelta-ssl.ts) writes the file and rewrites the URL to sslmode=verify-ca&sslrootcert=/workspace/supabase/.temp/pgdelta/pgdelta-target-ca.crt, assuming the project dir is visible at /workspace inside the edge-runtime container.

Inside the container, that path doesn't exist → ENOENT. So either the workspace is staged into the container before the cert file is written, or the mount doesn't include supabase/.temp/pgdelta/.

Additionally, the prepare step also passes the PEM inline via the PGDELTA_TARGET_SSLROOTCERT env var — but @supabase/pg-delta@1.0.0-alpha.27's ssl-config.js getCertValue only handles file paths, so the env fallback that would have saved this doesn't kick in. Either half working (file visible in container, or pg-delta honoring an inline PEM in the env) would fix it.

To Reproduce

1. Link any hosted project (supabase link --project-ref …).
2. Add a trivial migration.
3. supabase db push → migration applies, then the warning + double stack trace above.

Reproduces 100% of the time on two different hosted projects (two different orgs/regions).

Expected behavior

The catalog cache step connects successfully (cert visible at the path baked into the URL, or inline PEM env honored) — or at minimum fails with a one-line warning instead of a double-printed runtime crash.

System information

• OS: macOS 27.0 (Apple Silicon)
• Docker: 29.6.1
• Version of CLI: v2.109.1 (Homebrew; also confirmed no fix mentioned in 2.110.0 betas)
• pg-delta: @supabase/pg-delta 1.0.0-alpha.27
• Versions of services: hosted projects, Postgres 17.6.1.127

[avallete]

Thank's for the report, a fix has now been merged and should be available on the beta channel. You can give it a try with npx supabase@beta and let us know if you hit any more issue.