Hey there! We've found the following might help you get unblocked faster:

• 🧵 my service can't connect to the postgres database

• 🧵 Can't get correct DB connection

• 🧵 Can't connect to postgres using internal URL

If you find the answer from one of these, please let us know by solving the thread!

hyy;

that P1001 thing is basically your container not being able to find the database hostname which happens a lot with Alpine images if ur using those.

first thing I'd try is checking what base image you're running in your Dockerfile. If it says something like FROM node:alpine then you prob need to flip on Alpine private networking. Just go into your evolution-api service settings and throw in a new environment variable called ENABLE_ALPINE_PRIVATE_NETWORKING and set it to true. Redeploy after that and see if it helps since Alpine handles DNS kinda weirdly in Railway's network.

If that doesn't do it maybe try adding a little pause before your migrations run. like in whatever startup script you got (runWithProvider.js or wherever) just stick a sleep 5 && before the npx prisma migrate deploy command. Sometimes the network just needs a sec to actually be ready before Prisma tries connecting.

also worth checking when your Railway project was created. If it's from before like mid October 2025 it might be on their old IPv6 only setup which Prisma really doesn't like. If that's the case you'd need to spin up a fresh environment in Railway and move everything over to get IPv4 support.

I'd start with that environment variable since that's usually the culprit. But if ur not on Alpine (like if you're using node:bookworm or something) then skip that and try the sleep thing instead. Lmk how it goes or if you're still stuck

bytekeim

I have this same problem. I've created my service this november. I didn't know about ENABLE_ALPINE_PRIVATE_NETWORKING but it did not help me. I did however manage to get it to work by providing an absurd high connect_timeout. I remember this being a problem since a long time ago. Unsure if this is a prisma-specific problem or just a pg problem.

yes combine with other Params, Add &pool_timeout=30&socket_timeout=30 for better handling of pooling delays in prisma, this addresses intermittent networking or wake-up latencies in hosted Postgres setups , if that doesn't fix it, consider adding a startup delay in your script (e.g., sleep 5) before migrations

Hmm, just tried to use the normal base image for node(bookworm) and then it worked like a charm. No more ugly connect_timeout, custom scripts or ENABLE_ALPINE_PRIVATE_NETWORKING!

FROM node:24 AS base

that's awesome, bookworm's got proper glibc and better networking support out of the box so it just works. trade-off is a slightly bigger image but honestly worth it for not having to deal with those weird timeouts and hacks.

glad you got it sorted!

bytekeim

Thank you for your response. I too created my environment this November. Adding sleep didn't help, nor adding the ALPINE variable. But I spun up a fresh environment and it seemed to do the trick. So thanks!

I've also spun up new environments and they worked for 2-3 days and only after that time, the problem began to occur again so keep that in mind if it starts happening again.