storage container unhealthy after v2.77.0 (storage-api v1.41.8)

[zlotnika]

Bug report

Describe the bug

After upgrading from CLI 2.76.8 to 2.77.0, supabase start intermittently fails with:

supabase_storage_<project> container is not ready: unhealthy

The storage container logs show it started successfully:

{"level":30,"msg":"Server listening at http://0.0.0.0:5000"}
{"level":30,"msg":"[Server] Started Successfully"}

But the health check still fails.

To reproduce

Run supabase start in CI (GitHub Actions, ARM runner). Fails ~50% of the time. Pinning back to 2.76.8 resolves it.

Expected behavior

supabase start should reliably pass health checks.

Root cause (suspected)

v2.77.0 bumped supabase/storage-api from v1.41.3 to v1.41.8 via #4935.

Storage v1.41.8 added a DB connection pool monitor (startMonitor in src/internal/database/pool.ts) that starts a setInterval tracking connection metrics. This appears to race with the health check on startup — the server reports ready but the health endpoint isn't passing yet, possibly because the pool monitor hasn't initialized or is interfering with the readiness signal.

Relevant storage commits: supabase/storage@v1.41.3...v1.41.8

Environment

• OS: Ubuntu 24.04 ARM (GitHub Actions)
• CLI version: 2.77.0
• Docker: GitHub Actions default
• Workaround: pin to 2.76.8