Pre-deploy command cannot reach private Postgres; database receives zero SQL across repeated deployments

pepperoney

HOBBYOP

a day ago

Hi Railway team,

I’m seeing a reproducible issue where a pre-deploy Prisma migration command appears unable to reach PostgreSQL over Railway private networking.

Project

Project: TodoTuna.es

Project ID: 0506f39b-5a94-4d31-ad07-237f6fb7e01e

Environment: staging

Environment ID: 5254df56-1da6-4a90-9e84-64eb9103b612

Web service: e3d30b15-de14-4bb4-be00-fa56dc29bf2f

Postgres service: c927b5d6-0cb2-490a-8c28-47987bac5aad

Region: europe-west4-drams3a

Source SHA: 081f09258d33d1c137ac0c5da0380c45fbcd2e51

Failure

Docker build and image publish succeed.

Deployment then fails during this pre-deploy command:

cd db-migrator && node_modules/.bin/prisma migrate deploy

The app never reaches runtime.

DATABASE_URL is a Railway reference to the staging Postgres private hostname:

postgres.railway.internal:5432/railway

Postgres itself is healthy.

Reproductions

Four deployment attempts failed with the same pattern.

Latest same-region failures:

59f0db46-17b7-4b7e-a944-a9df378e5dd9
722e615f-c081-42ee-867b-d763f1219697

Earlier failures:

ff98a944-82fa-4299-9729-5b98748f87bd
ee60abae-7e6a-4134-9dfd-85b5c89259ee

The latest two ran with both web and Postgres in europe-west4-drams3a.

CLI deploy logs contain essentially no useful stdout/stderr from the failing pre-deploy step.

Database evidence

I connected directly to the staging Postgres service via Railway SSH and ran read-only checks after the failures.

Results:

_prisma_migrations does not exist
public schema table count = 0
pg_trgm is not installed
no migration has ever been applied

This was confirmed again after the two same-region deployment failures.

So Prisma never successfully executed even the first migration against this database.

Application-side validation

I built the exact production Dockerfile locally from the exact same SHA.

Inside the final runtime image I confirmed:

db-migrator exists
Prisma 7.10.0 runs
prisma validate succeeds
schema is present
all 13 migrations are present
correct Linux/musl Prisma engine is present

I also ran the exact pre-deploy command with a deliberately unreachable test DB. It starts correctly, loads Prisma config/schema/migrations, and reaches the DB connection stage, producing the expected Prisma P1001: Can't reach database server.

So the image, Prisma CLI, command path, schema and migrations appear healthy.

Expected behavior

My understanding is that Railway pre-deploy commands run inside the private network and should be able to reach services in the same environment via *.railway.internal.

Actual behavior

Pre-deploy fails before Prisma executes any SQL at all.

Request

Could you please check the platform-side logs for these deployment IDs and confirm:

whether the pre-deploy container resolves postgres.railway.internal;
whether it establishes a TCP connection to port 5432;
the actual pre-deploy stdout/stderr or exit reason;
whether there is a known issue with private networking from pre-deploy containers;
whether any Railway-side configuration is missing for this setup.

I have intentionally not exposed Postgres publicly or switched to a public DATABASE_URL, because private networking is the intended architecture.

Thanks.

Awaiting Conductor Response$10 Bounty

3 Replies

Railway

BOT

a day ago

This thread has been opened as a bounty so the community can help solve it.

Status changed to Open Railway • 1 day ago

mayori

MODERATOR

a day ago

Make sure postgresql and the backend service is in the same project and environment

mayori

Make sure postgresql and the backend service is in the same project and environment

pepperoney

HOBBYOP

a day ago

Yes — they are definitely in the same Railway project and the same environment.

Project:

TodoTuna.es

Project ID:

0506f39b-5a94-4d31-ad07-237f6fb7e01e

Environment:

staging

Environment ID:

5254df56-1da6-4a90-9e84-64eb9103b612

Backend/web service ID:

e3d30b15-de14-4bb4-be00-fa56dc29bf2f

Postgres service ID:

c927b5d6-0cb2-490a-8c28-47987bac5aad

Both are also in the same region:

europe-west4-drams3a

The web service's DATABASE_URL is a Railway reference to the Postgres service in that same staging environment and resolves to:

postgres.railway.internal:5432/railway

Postgres is healthy and reachable through Railway SSH.

The issue only occurs from the web service's pre-deploy command. After multiple failed pre-deploy attempts, direct read-only inspection of Postgres still shows:

_prisma_migrations does not exist
0 public-schema tables
no migration has ever run

So Prisma appears to fail before executing any SQL.

Could you please check whether the pre-deploy container can resolve/reach postgres.railway.internal:5432, or whether there is any platform-side pre-deploy networking/log output for the deployment IDs I provided?

pepperoney

HOBBYOP

12 hours ago

That was it — your suggestion fixed the issue.

I changed the staging pre-deploy command to explicitly invoke /bin/sh -c, and the next deployment succeeded.

The logs showed both diagnostic markers:

predeploy: shell started

predeploy: launching prisma

Then Prisma connected successfully to:

postgres.railway.internal:5432

and all 13 migrations were applied, including the latest M2 migration.

The app then started normally, and the staging site is now live. I’ve also tested registration and transactional email successfully.

So the problem was indeed at the command-launch boundary: the original pre-deploy command relied on shell syntax (cd ... && ...) without explicitly invoking a shell.

We’re now persisting the fix in our Railway IaC as:

/bin/sh -c 'cd db-migrator || exit 1; exec node_modules/.bin/prisma migrate deploy'

Thank you very much for pointing us in the right direction — this saved us from chasing the database/private-networking side any further. Hopefully this thread is useful to anyone else who hits the same pre-deploy behavior.

Welcome!