#help Private networking: postgres.railway.internal connect timeout after Postgres volume remount; public proxy works
emileinarsen
PROOP

3 months ago

Workspace: Hagatun IT

Project: Fleet Analyzer

Project ID: 29384a88-9816-4694-b661-948a68e70025

Environment: production (64399704-8a81-4d68-a388-132a4cfc213c)

Services:

  • Dashboard: 2858b60e-f607-47bd-b980-d93db019ad80
  • Postgres: 6dddc998-fff8-40b3-9d19-e06e98fdf327
  • Worker: 0f29e0df-fa0a-44be-afff-8532f619b836

Related / same symptoms

https://station.railway.com/questions/private-networking-service-cannot-reach-3d1be833

Same pattern reported there: private host times out, DATABASE_PUBLIC_URL works, Postgres itself is healthy.

Summary

After a Postgres restart / volume remount, services in the same project/environment cannot connect to Postgres over private networking. The public TCP proxy works. Production is currently mitigated by pointing Dashboard at DATABASE_PUBLIC_URL.

Timeline (UTC)

  • ~2026-07-18 17:15: Postgres logs stop normal activity and show:

    "Mounting volume on: .../vol_v49eqi9tdokti534"

  • 2026-07-19 ~12:36+: production site down; Dashboard pre-deploy

    pnpm run --filter @btr/core db:migrate exits 1 with little/no migrate output

  • After Postgres restart, Dashboard starts and Redis connects over private networking, but Postgres fails repeatedly with:

    "PgClient: Connection timed out" / "Connection terminated due to connection timeout"

  • Healthcheck /resources/healthcheck fails because it requires DB connectivity

Reproduction / evidence

  1. Dashboard DATABASE_URL was (and is normally):

    ${{Postgres.DATABASE_URL}} → host postgres.railway.internal:5432

    Result: connect timeouts from Dashboard container. No useful auth/connection errors in Postgres logs during those attempts.

  2. From my laptop against public proxy:

    psql -h tramway.proxy.rlwy.net -p 44024 -U postgres -d railway

    SELECT 1; → success (SSL works)

  3. Workaround that restored production:

    Dashboard DATABASE_URL = ${{Postgres.DATABASE_PUBLIC_URL}}

    Redeploy → migrate + healthchecks succeed, site up.

  4. Switching back to ${{Postgres.DATABASE_URL}} fails again with the same private-network timeouts.

Notes

  • Dashboard and Postgres are in the same project and environment (production).
  • Redis private connectivity from Dashboard continued to work while Postgres private did not.
  • This does not look application-level: same app works immediately when only the DB URL host changes from internal → public proxy.

Ask

Please investigate private networking / DNS / routing between Dashboard and Postgres in this environment (same class of issue as thread 3d1be833). Public proxy works; private host postgres.railway.internal does not from the Dashboard service after the volume remount/restart.

Happy to provide additional deploy IDs, metrics screenshots, or a temporary shell if needed.

Solved$20 Bounty

5 Replies

Railway
BOT

3 months ago

This thread has been opened as a public bounty so the community can help solve it. The thread and any further activity are now visible to everyone.

Status changed to Open Railway • 3 months ago


pedromidueno
HOBBY

3 months ago

Hi, do you have an app layer between your dashboard and postgres (like a backend or web server)? Or are you making the requests from your frontend directly to postgres?


emileinarsen
PROOP

2 months ago

Dahboard is a tanstack/start BFF, no other layer between


pedromidueno
HOBBY

2 months ago

I think you cannot make a request from the browser through the railway private network


emileinarsen
PROOP

2 months ago

I'm not. I make the DB calls on the server (the sever to DB is over private). Which has been working for over a year now. It just randomly stopped working


emileinarsen
PROOP

2 months ago

Tried switching back to private and today, and seem to have resolved itself. Some internal railway issue perhaps


Status changed to Solved 0x5b62656e5d • 2 months ago


Welcome!

Sign in to your Railway account to join the conversation.

Loading...