Private networking is not available during the build phase, so your Next.js build cannot reach your backend over railway.internal. To reduce network egress costs, you can restructure your Next.js app to fetch data at runtime (server-side) rather than at build time, since private networking is available during runtime.

Hello,

so the root cause is confirmed in railway's official docs: private networking is only available at runtime, not during the build phase. so no matter what you do, nextjs can't reach the private domain while building, that's why it falls back to the public one and you get charged

the fix depends on how you're fetching data. if you're fetching from your nestjs backend at build time (getstaticprops, generateStaticParams etc), move that logic to run at runtime instead. at runtime the private network is available and you can reach your nestjs service at http://your-service-name.railway.internal:port

two things to keep in mind from the docs: use http not https (railway already encrypts internal traffic with wireguard), and internal traffic doesn't count toward egress billing so your costs will drop once you make the switch.

source: docs.railway.com/networking/private-networking/how-it-works

Hope this help you :)

Hey so I think

Internal DNS / Service Discovery (The Cleanest Fix)

Instead of hardcoding your public URL use the internal service name or private IP provided by your infrastructure (Kubernetes, Docker Compose, AWS ECS, etc.).

In Docker/Kubernetes: Use the service name. If your NestJS service is named backend, your build-time URL would be http://backend:3000.

In AWS/GCP Use the Internal Load Balancer (ILB) DNS name or the private IP.