The first thing I would check is where Prisma is trying to connect from.

Railway Static Outbound IP applies to traffic from the running service replica. If prisma migrate deploy, prisma db push, or any DB check runs during the build phase, that traffic may not be coming from the same static egress path as the deployed service. That can look exactly like this: deploy sometimes fails with P1001, but the app works after enough redeploys.

Recommended setup:

1. Do not run DB network calls in npm install, postinstall, Docker build, or Railway build command. Build should do only prisma generate and app compilation.
2. Run migrations after the container starts, from a service that has Static Outbound IP enabled, or create a small dedicated migrate service/job in the same project that runs npx prisma migrate deploy and exits.
3. In Prisma with Neon, use two URLs:

datasource db {
  provider  = "postgresql"
  url       = env("DATABASE_URL")
  directUrl = env("DIRECT_URL")
}

• DATABASE_URL: Neon pooled connection string for normal app traffic.
• DIRECT_URL: Neon direct connection string for migrations.

1. Keep sslmode=require and raise timeout on the direct URL, for example connect_timeout=30.
2. If you have Prisma commands in the app start command, make them explicit and fail-fast, e.g. npx prisma migrate deploy && npm run start, rather than hiding them in package scripts.

How I would confirm the cause:

• Temporarily remove any Prisma DB command from the build phase and deploy.
• Open a Railway shell/one-off command from the running service with Static Outbound IP enabled and run:

npx prisma migrate status
npx prisma migrate deploy

If that works reliably from the running service but not during build, the issue is build-time egress vs runtime egress.

Also double-check region and URL choice:

• Your Neon endpoint is ap-southeast-2. If the Railway service is in a far region, TLS/connect timeouts are more likely under static egress. Put the Railway service in the closest available region.
• For app runtime, prefer the Neon pooled endpoint. For migrations, use direct URL. Using the pooler for migrations can cause odd migration/lock behavior.
• After enabling Static Outbound IP, redeploy the service so the running replica is actually using that networking config.

If it still fails after moving all DB access to runtime/static egress, then I would open Railway support with: service ID, deployment ID, region, static outbound IP enabled, exact timestamp of a P1001, and confirmation that the same command succeeds when static IP is disabled. That narrows it to Railway static egress/NAT routing rather than Prisma or Neon config.