Make sure that you have the PORT env variable set to 3001.

The PORT/binding angle is already ruled out based on what you've shared, so here's a different theory worth checking: connection pool exhaustion during the deploy overlap window, specifically with Supavisor's Session Pooler.

During a rolling deploy, Railway keeps your old container ACTIVE and serving traffic while the new container boots and goes through its healthcheck — that's exactly why the old one stays healthy throughout. For that window, you have two containers alive simultaneously, both trying to hold connections against the same Supavisor pool.

Session mode (unlike Transaction mode) holds one dedicated backend connection per client for the life of that session. If your existing container is already holding most or all of the pooler's session slots — especially with a worker doing a DB operation every 5 seconds — the new container spinning up alongside it may not be able to acquire its own connections. That would produce exactly what you're seeing: the new container's worker can't claim work (messaging_worker_claim_failed), throws unhandled exceptions, and if your /health check includes a database.status check, the healthcheck fails — while the old container, whose connections were already established before the new one existed, keeps working.

Worth checking:

1. Your Supavisor pool's configured max connections vs. your app's own DB client pool size (e.g. Prisma/TypeORM connectionLimit) — multiply that by 2 during the overlap window and see if it exceeds the pooler's limit.
2. Whether your background worker's DB queries could run through the Transaction pooler instead of Session mode — transaction mode multiplexes far more clients over the same backend connections, which would make this kind of overlap non-issue.
3. As a quick mitigation regardless of root cause: add retry-with-backoff around the worker's claim function instead of letting it hard-fail on the first attempt during startup — that alone might get you through the overlap window without failing the deploy.

If you can check Supavisor's dashboard for connection count during one of these failed deploy windows, that would confirm or rule this out directly.

Thanks for this — really helpful angle, and different from anything we'd tested so far.

I checked our Supabase project's Connection Pooling settings (Settings > Database):

• Connection pool size: 15 (backend connections to Postgres, per user+db)
• Max client connections: 200

Since we're on Session mode (not Transaction), the number that matters for us is the 15, since each session-mode client holds one of those slots for its whole lifetime.

Our app doesn't set an explicit connection_limit on the Prisma side, so each container defaults to Prisma's formula (num_cpus * 2 + 1) — with 2 vCPU that's ~5 per container. During the deploy overlap window, that would be old container (~5) + new container (~5) = ~10, which is still under the 15 pool size limit on paper. So the simple arithmetic doesn't obviously confirm the theory, though it doesn't rule it out either — we don't have a connection count captured from Supavisor's own side during one of the actual failed windows (only a quiet-traffic snapshot from Postgres' pg_stat_activity taken separately, which isn't the same thing).

If you have thoughts on reconciling that gap (e.g., whether Session mode connections can pile up higher than the nominal connection_limit under real traffic, or another way the two containers together could exceed 15), I'd be glad to hear them. We can also try capturing Supavisor's connection count live during a redeploy attempt if that would help narrow it down further.