Despite this, the application always falls back to SQLite at runtime

Does it fall back to SQLITE automatically if it doesn't have a DATABASE_URL variable? Asking so I know the scope of the problem

The DATABASE_URL environment variable

Just to be clear, on Railway there are two areas where you can define variables: the project and the service. Can you confirm where you're applying the variables? I want to make sure it's being applied at the same place.

used both the ${{MySQL.VAR}} reference syntax and a hardcoded internal MySQL URL

For the reference variable, you can confirm it injected by revealing the variable (via the eye icon) after your service deploys. Mind clarifying what you mean with "hardcoded internal MySQL URL"? Do you mean copied and pasted the database url directly into the DATABASE_URL variable?

Yes, our own application code defaults to SQLite only when the DATABASE_URL environment variable is not found via os.environ.get() — this is expected behavior on our end, confirming the variable isn't reaching the app.

I've been setting variables at the service level (on the "web"/"acadia" service directly, via its own Variables tab), not as project-level shared variables.

By "hardcoded", yes — I mean I pasted the full connection string directly as the value, like: mysql+pymysql://root:PASSWORD@mysql.railway.internal:3306/railway (copied from the MySQL service's own MYSQL_URL variable).

Yes, our own application code defaults to SQLite only when the DATABASE_URL environment variable is not found via os.environ.get() — this is expected behavior on our end, confirming the variable isn't reaching the app.

I've been setting variables at the service level (on the "web"/"acadia" service directly, via its own Variables tab), not as project-level shared variables.

By "hardcoded", yes — I mean I pasted the full connection string directly as the value, like: mysql+pymysql://root:PASSWORD@mysql.railway.internal:3306/railway (copied from the MySQL service's own MYSQL_URL variable).

Thank you for confirming!

In that case it sounds like you did everything correctly, the only thing left is to verify that the variable is getting injected into the deployment. This is a trivial thing to verify, mind clicking on your service (while its running), you'll see a console tab. In there just enter echo $DATABASE_URL, if it logs your variable then it means the variable is being injected and your app is incorrectly using sqlite, if it isn't being injected then we know the issue lies somewhere between the service variables and the deployment

The service is crash-looping (worker fails to boot repeatedly due to the DATABASE_URL/SQLite issue), so the Console tab shows "Disconnected" and I cannot type or run any command in it — the container never stays stable long enough for an interactive session to work.

Since I can't verify this from my end, could you please check server-side whether the DATABASE_URL environment variable is actually being injected into this specific service's container at deploy/runtime? The variable is confirmed present and correctly formatted in the service's Variables tab (verified via the eye icon).

I managed to access the Console after a redeploy. I ran echo $DATABASE_URL and nothing was displayed (empty output) — confirming the variable is NOT actually injected into the container's environment, despite being correctly set and visible (verified via the eye icon) in the service's Variables tab.

This confirms the issue is server-side: the variable shown in the dashboard isn't reaching the actual runtime environment of this service. Could you please investigate why?

Project ID: 9909836d-4022-47a0-98c6-9ba0c1893f96

Would you be able to send a screenshot of a variable in your service variables (please do not reveal anything sensitive by doing this), I just want to confirm you're setting it in the right place and in the right way. Also worth checking, often times people miss that they need to hit the Apply Changes button on the UI after staging a service variable. Have you been doing that?

No, I don't see an "Apply Changes" button anywhere on this page. I've attached a screenshot of my Variables tab (sensitive values hidden) for reference. I also tested with a simple variable (TEST=bonjour) with the exact same result — completely empty when running echo $TEST in the Console, ruling out any issue with special characters in the DATABASE_URL value.

Hi, I just wanted to follow up and say thank you — the issue is resolved! It turned out I needed to click the purple "Deploy" button at the top of the Variables page after adding my environment variables, rather than using "Redeploy" on an existing deployment from the history. That's what actually applied the variables to a fresh build.

The application now connects to MySQL correctly and everything is working. Thanks for your patience and for guiding me through the console check — that step was key to confirming the variables weren't being picked up, which pointed us in the right direction.

Really appreciate the help

Awesome, glad that worked! Happy I could be of help 🙂