Hey there! We've found the following might help you get unblocked faster:

• 🧵 Error deploying Rails app - Database URL cannot be empty

• 🧵 Deployment crashed due to server connection not established (postgresql)

• 🧵 Issue running rake or seeds file from Rails to connected Postgres

If you find the answer from one of these, please let us know by solving the thread!

I already found those answers, and none got me on the right track.

During my many, many failed deployments, I realized one thing: if I set RAILS_ENV to "development" instead of "production", it can connect to the database. No idea why. But I remember seeing an answer from Angelo about this. If I set to "development", I can go a bit further, but then I get an issue with Rails complaining that it cannot find the Vite binary (though when I deploy my server, I can see Vite building the chunks). I'm guessing the Vite error happens because it believes it is in a dev environment and expects on-the-fly creation javacsript chunks... whereas if it was in production (i.e. RAILS_ENV = production), it would know that chunks were already created and use them instead. Something like that ?

Continuing on my quest to try understand why RAILS_ENV=development works and not RAILS_ENV=production. Something bothers me : in my deployment.yml, the "development" database does not at all use the DATABASE_URL environment variable. Why then does it work when deploying in Railway ? Or maybe... in fact it doesn't work, it's just Rails (in Railway) ignores it for now, as another issue is happening with Vite (as stated above), and Rails didn't yet have the chance to try and connect to the db. Back to square one: why can't the Rails service connect to the DATABASE_URL when RAILS_ENV=production ?

(sorry, just talking to myself, trying to understand what's going on...)

... and now I could get it running with RAILS_ENV=production but... I had to copy-paste the entire URL of the database in the database.yml (with the username and pwd). So there is something wrong when using the variables in Railway (i.e. if I refer to DATABASE_URL in database.yml, my app cannot connect to the db).

No idea why, but now it works. I went from setting the public URL of the database directly in deploy.yml; it worked. Then I tried with the internal URL of the database; it worked. Finally I updated the deploy.yml using <%=ENV['DATABASE_URL] %> (so going back to the state I was at the beginning), updated the DATABASE_URL to ${{Postgres.DATABASE_URL}} (in my Rails service)... and it worked. I'm keeping this thread opened though, in case it breaks again.

hi, your rails app is trying to connect via a local socket because DATABASE_URL isn’t being picked up in production. make sure it’s set correctly in railway, referenced properly in database.yml, and that you redeploy after setting it. that should fix the connection issue.

Thanks for the feedback and suggestion. As stated in my initial message, I believe my whole setup was correct. database.yml referenced DATABASE_URL, and my Rails app in Railway had a variable called DATABASE_URL = ${{Postgres.DATABASE_URL}} ("Postgres" being the name of the db created in Railway). Still I got the issue about the socket. I tried many different things, and as said in my last post, for some reason, now it works. I really don't understand why it did not work the first time, as in the end I went back to the first setup. It is "solved" I guess, but I don't understand how and why.

yeah, this kind of issue often comes down to runtime environment mismatch or delayed env injection. even if DATABASE_URL is correctly set in Railway, the container may not pick it up unless the service is fully redeployed (not just restarted), so the build and runtime layers both re-evaluate env vars

config/database.yml is evaluated at boot, so if ENV["DATABASE_URL"] wasn’t available yet (e.g. build-time vs runtime), Rails might default to the UNIX socket connection

sometimes, cached Docker layers or improper RAILS_ENV values (like accidentally using development in production) can lead to weird fallback behavior

in short: the setup was probably correct, but until the app was fully rebuilt or restarted cleanly, it may have been running stale config or misreading envs.

mystery solved (kinda) but definitely a classic “works after redeploy” bug.

Thanks for the comment. I have to say to this is not really reassuring I just added a second database for solid_cache, and it worked right away ... as I thought it would 3 days ago. I'll keep this thread opened for a few more days in case I encounter another issue with these ENVs...

No more issue for a long time now, I will close this thread.