add this before your sqlx connection in main.rs:

tokio::time::sleep(tokio::time::Duration::from_secs(3)).await;

or better, add retry logic:

let mut retries = 5;
let pool = loop {
    match PgPoolOptions::new().connect(&database_url).await {
        Ok(p) => break p,
        Err(_) if retries > 0 => {
            retries -= 1;
            tokio::time::sleep(tokio::time::Duration::from_secs(2)).await;
        }
        Err(e) => return Err(e.into()),
    }
};

your postgres.railway.internal:5432 url is correct, just needed the timing fix

let me know the result

Thanks for the suggestions! Here's an update on what I tried:

What worked:

• Added SQLX_OFFLINE=true environment variable → Build now succeeds

• Implemented your retry logic (5 retries, 2s intervals) → Code compiles and runs

What didn't work:

• Private DNS (postgres.railway.internal:5432) still fails to resolve after all retries

• Backend crashes every ~20 seconds with: "failed to lookup address information: Name or service not known"

• Tested multiple DNS formats: postgres.railway.internal, postgres, short service name - all fail

Current workaround:

• Using public proxy endpoint (hopper.proxy.rlwy.net:56166) → Works perfectly

• Backend is now ACTIVE and serving requests

Questions:

1. Is there a known issue with private networking in us-east4-eqdc4a region?

2. Could this be a project-specific DNS propagation issue?

3. Should I try recreating the PostgreSQL service?

The retry logic was solid advice and would have worked if DNS resolved. For now, I'm running on the public endpoint until we figure out the private networking issue.

Thanks again for your help!

glad the retry logic worked! the private dns still failing though suggests one thing:

are both services in the exact same environment?

railway's private networking only works when services are in the same environment (not just same region). if your postgres is in one environment and backend is in another, private dns will never resolve

check this open your railway project then look at the environment dropdown at the top and verify both postgres and backend are listed in the SAME environment

if they're in different environments, you have two options either recreate one service in the same environment as the other, or keep using the public endpoint (which works cross-environment)

this would explain why public works but private dns completely fails even with retries. let me know what you find!

Good catch on the environment check! I verified and confirmed:

All 3 services are in the same environment:

• Bytus Frontend → production

• Bytus Backend → production

• Bytus Database (PostgreSQL) → production

All services are also in the same region: us-east4-eqdc4a

What I've verified:

• Same project

• Same environment (production)

• Same region

• Private networking enabled on PostgreSQL

• Retry logic works (5 retries, 2s intervals)

• DNS still fails: "failed to lookup address information: Name or service not known"

Tested DNS formats (all failed):

• postgres.railway.internal:5432

• postgres:5432

• Service short name variations

Current workaround: Public endpoint works perfectly, so I'm running with that for now.

Any other ideas on what could cause private DNS to completely fail even when everything is in the same environment?

this is for legacy runtime only : i made an assumption that your rust docker images use alpine, if yes ; i think i found it , add this environment variable to your backend service (the one making the postgres connection):

ENABLE_ALPINE_PRIVATE_NETWORKING=true

then redeploy this should fix the DNS resolution completely. the retry logic you added is good to keep, but the alpine flag is the actual fix for the DNS not resolving at all

let me know the result

Hey ilyassbreth,

So you don't go chasing geese, I want to mention that OP does not have their backend and database in the same environment, despite them saying it multiple times. The backend and database are in completely separate projects; in fact, the backend, frontend, and database are all in different projects.

Additionally, this variable was needed only on the legacy runtime, but as of several months ago, we have precisely zero deployments that use the legacy runtime.

thanks brody! that explains everything, i asked chronocoders about that ; so not just separate environments, but entirely different projects. no wonder private dns was completely failing. appreciate you catching that, saved us from chasing the wrong solutions

Thanks everyone for the help and explanations — after reviewing everything more carefully, I see that you were right.

Even though I was thinking of frontend, backend, and database as parts of the same logical “Bytus” project, in Railway they are actually deployed as separate projects. Because of that, private networking and private DNS resolution cannot work between them, regardless of region or environment settings.

So the DNS failure makes sense now, and the behavior we’re seeing is expected. Using the public proxy endpoint is the correct approach for this setup, unless we move all services into the same Railway project.

Appreciate the patience and the clarifications — this helped clear up my misunderstanding.

Thanks everyone for the help and explanations — after reviewing everything more carefully, I see that you were right.

Even though I was thinking of frontend, backend, and database as parts of the same logical “Bytus” project, in Railway they are actually deployed as separate projects. Because of that, private networking and private DNS resolution cannot work between them, regardless of region or environment settings.

So the DNS failure makes sense now, and the behavior we’re seeing is expected. Using the public proxy endpoint is the correct approach for this setup, unless we move all services into the same Railway project.

Appreciate the patience and the clarifications — this helped clear up my misunderstanding.

glad that cleared things up! just to confirm the environment check i mentioned earlier was on the right track (services needing to be in same project/environment for private networking), it just turned out the issue was at the project level rather than environment level. either way, you've got it working now with the public endpoint which is the right call for your current setup. good luck with Bytus!

I strongly recommend moving your frontend and backend into the same project as your database so you can use the private network. Otherwise, you will be paying egress fees when talking to your database over the public network, not to mention there would be added latency with the public network vs. the private one.

https://docs.railway.com/overview/best-practices#deploying-related-services-into-the-same-project