Password regeneration through the database Config tab updates the Postgres service's variables and keeps them in sync, but dependent services must be redeployed afterward to pick up the new values through their reference variables. The most common cause of this mismatch is timing: if the application service was redeployed before the Postgres service's own redeploy (triggered by the regeneration) finished, the app can resolve the reference to the old password. The safe recovery step is to redeploy the application service again now, which will re-resolve ${{Postgres.DATABASE_URL}} against the current (regenerated) credentials. Your database volume and data are not affected by any of this. If the auth failure persists after a fresh redeploy, confirm in the application service's Variables tab that DATABASE_URL is set as a reference (it will show the ${{...}} syntax) rather than a hardcoded literal value.

Project: desirable-growth

Environment: production

Postgres service status: SUCCESS

The application service nahla-saas now references:

${{Postgres.DATABASE_URL}}

Railway created deployment:

b28e9308-7198-4c37-8599-6562d07ad6a4

Status: SUCCESS

Post-deployment sanitized runtime evidence:

• DNS resolution succeeds
• Raw TCP connectivity succeeds
• PostgreSQL password authentication remains rejected
• SQL health verification cannot proceed

Please verify internally whether the credentials exposed through

Postgres.DATABASE_URL match the credentials currently accepted by the

Postgres instance, including managed-reference propagation after password

regeneration.

No URLs, usernames, passwords, tokens, hashes, or resolved credentials

are included.

Hello! If you are using a reference variable ${{Postgres.DATABASE_URL}} you will need to redeploy the consuming application (likely your API / backend) after the password was regenerated. This will redeploy your service with the new database url / password. Have you tried that since running the password regeneration action on PostgreSQL?

Hello, thank you for your response.

Yes, we already completed that exact procedure:

1. We replaced the stale service-scoped DATABASE_URL value in nahla-saas with the managed reference:

${{Postgres.DATABASE_URL}}

1. Railway then automatically created a new deployment for nahla-saas after the password regeneration and variable update.

Deployment ID:

b28e9308-7198-4c37-8599-6562d07ad6a4

Deployment status:

SUCCESS

However, after this deployment:

• DNS resolution succeeds
• Raw TCP connectivity to PostgreSQL succeeds
• PostgreSQL password authentication is still rejected
• SQL health verification cannot proceed
• The application remains unhealthy

No additional password rotations, variable edits, or redeployments have been performed.

Could you please verify internally whether the credentials currently exposed through Postgres.DATABASE_URL match the credentials actually accepted by the PostgreSQL instance, including managed-reference propagation after the password regeneration?

No URLs, usernames, passwords, tokens, hashes, or resolved credentials are included in this message.

Found the problem. The regeneration did change the password on the database itself, but it only rewrote the POSTGRES_PASSWORD variable. On your Postgres service, DATABASE_URL, DATABASE_PUBLIC_URL, and PGPASSWORD are stored as hardcoded values instead of references to ${{POSTGRES_PASSWORD}}, so they still carry the old password.

Your reference in nahla-saas is resolving fine, the value it resolves to is just stale.

The fix needs no second regeneration and won't touch your data or volume. On the Postgres service, set these three variables to:

PGPASSWORD=${{POSTGRES_PASSWORD}}
DATABASE_URL=postgresql://${{PGUSER}}:${{POSTGRES_PASSWORD}}@${{RAILWAY_PRIVATE_DOMAIN}}:5432/${{PGDATABASE}}
DATABASE_PUBLIC_URL=postgresql://${{PGUSER}}:${{POSTGRES_PASSWORD}}@${{RAILWAY_TCP_PROXY_DOMAIN}}:${{RAILWAY_TCP_PROXY_PORT}}/${{PGDATABASE}}

Then redeploy nahla-saas. Leave POSTGRES_PASSWORD as is, it's already correct.

Hello, we completed a read-only investigation and located both database baselines.

No production changes were made.

Current application target:

• Postgres service ID: 15973ab3-d018-4117-8607-4140875166b3
• Attached volume ID: 9a0a8a9c-291f-4fb7-8791-9f2bf2089637
• Database name: railway
• Verified baseline: Alembic 0093 / Tenant 1 product count 20

A second active PostgreSQL target also exists:

• Service: nahla-postgres-prod
• Service ID: b77b3d27-47b0-4a3a-83fd-44def66a3a84
• Volume: postgres-volume-hU16
• Volume ID: 009bd0d5-85ed-4de4-99fc-94ea963c9d65
• Database name: railway
• Verified baseline: Alembic 0096 / Tenant 1 product count 28

Both PostgreSQL services and both attached volumes are active. No detached historical PostgreSQL volume or usable backup inventory was exposed through our current Railway view.

Before making any further change, could you please confirm only this historical fact:

Which PostgreSQL service and attached volume did the resolved DATABASE_URL used by the nahla-saas deployment target at the time the 0096/28 production baseline was previously verified?

If available, please include the historical Railway managed-reference resolution or service-binding identity from that time, without exposing any URL, username, password, token, or credential.

Please do not modify variables, services, volumes, deployments, credentials, or databases. We are requesting historical identity confirmation only.

If you go into your previous deployments in a service, you can expand the deployment then go to the details tab to view which variables were set and injected at the deployments start time. This should tell you how your services were configured.

At this point, we are relatively confident this is not a platform issue but a configuration issue. Given you are on the hobby plan we can't provide application level support. Would you like us to open this up to the community so they can assist here?

Thank you. We will inspect the historical nahla-saas deployment details and its injected variables as you suggested.

Please do not open this discussion to the community at this time, as it concerns our private production configuration.

We will return only if the historical deployment details do not expose enough information to identify the previous service binding.

No platform or production changes are requested.