a month ago
Hi,
Hoping someone can confirm whether this is expected behaviour.
Setup: Python 3.13 / FastAPI / SQLAlchemy + psycopg2, Postgres in the same project, app and database in the same region.
What happened: our application container raised a psycopg2.OperationalError while trying to reach the public TCP proxy endpoint (*.proxy.rlwy.net) — even though DATABASE_URL on the app service is set to the private *.railway.internal hostname.
What I verified on my side:
The variable on the app service points to the private network
Our code reads only DATABASE_URL and never references DATABASE_PUBLIC_URL
A full repo grep for the public variable name and the proxy hostname returns zero matches in any .py, .yml or .sh file
create_engine() is called in exactly one place the app imports
So I can't explain how the container ended up dialling the public endpoint at all.
Questions:
Is there any condition where Railway substitutes or falls back to the public proxy — for example if private networking isn't ready yet at container startup?
Is there a variable change history available to users, so I can check whether the value differed a few days ago?
Separately: our container restarted three times in one day while we deployed only once. Memory is stable (~110–150 MB, no growth) and CPU is idle, so it doesn't look OOM-related. Is that normal platform behaviour — host migrations, health checks, or something else?
Thanks.
2 Replies
a month ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • about 1 month ago
a month ago
Railway doesn't do any "fallbacks." Do you perhaps have DATABASE_URL pointing to the public URL in your Railway service variables?
0x5b62656e5d
Railway doesn't do any "fallbacks." Do you perhaps have `DATABASE_URL` pointing to the public URL in your Railway service variables?
a month ago
I did check: DATABASE_URL on the app service currently points to the private *.railway.internal hostname, and my code reads only that variable (verified with a full repo grep — no reference to the public variable or the proxy hostname anywhere).
The catch is that I checked it today, and the error happened two days ago. So if Railway never falls back, the only remaining explanation is that the variable held a different value at that time.
Is there any way for a user to see the variable history for a service, or the environment snapshot a specific deployment was started with? That would settle it either way.