19 days ago
Hi! I need help with two related issues.
-
I subscribed to the Hobby plan, but on the wrong workspace. My plan is active on "Workspace A" (which only has an empty project). But my main project (a Node app service "sistema" + a Postgres database) is on a different workspace ("Workspace B") that is still on Trial. I need the Hobby plan to apply to Workspace B. How do I move the project or the plan so they're together?
-
My app service ("sistema") deploys and starts fine, but every database query fails at connection time:
DATABASE_PUBLIC_URL ([my Postgres public proxy host]) with SSL -> "error establishing an SSL connection"
DATABASE_URL (postgres.railway.internal:5432) without SSL -> "Connection terminated unexpectedly"
I'm using Node with the pg library. I've already tried: ssl { rejectUnauthorized: false }, sslmode=no-verify, ssl: false, keepAlive, higher connectionTimeoutMillis, and pinning pg to 8.11.5 -- none worked. The public URL also fails from my local machine now, even though it worked before. The Postgres service shows as Online.
Could you help me (a) get the Hobby plan onto Workspace B, and (b) fix the database connection between my app service and Postgres in that project? Thank you very much!
2 Replies
Status changed to Awaiting Railway Response Railway • 19 days ago
19 days ago
On this account we can see one workspace with the Hobby plan active, and the only service in it is a Postgres database - there is no "sistema" app service here. If your app lives in a second workspace, that workspace may be on a different Railway account (e.g. a different login). Check the workspace switcher in the dashboard to confirm which account you are signed into.
To get everything together, you can transfer the project containing your app into the workspace that has the Hobby plan. Both the source and destination workspaces need an active paid plan (Hobby or Pro) for the transfer: https://docs.railway.com/guides/projects#transferring-projects
One important note on the internal connection: postgres.railway.internal only resolves between services deployed in the same project and environment. If "sistema" is in a different project or workspace than the Postgres service, that path will never connect - they must be in the same project.
Status changed to Awaiting User Response Railway • 19 days ago
19 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 19 days ago
16 days ago
I think these are two separate issues.
- Hobby plan on the wrong workspace
Railway subscriptions are attached to the workspace, not individual projects. There isn't a self-service way to move a paid Hobby subscription from one workspace to another. Your options are:
Contact Railway Support and ask them to transfer the Hobby subscription to Workspace B (they've helped with this in the past), or
Move your project into the workspace that already has the Hobby plan, if that's feasible.
- PostgreSQL connection issues
Since both the public and internal connections suddenly stopped working, this doesn't look like a typical SSL configuration problem.
A few things to verify:
Ensure your application and PostgreSQL service are in the same Railway project if you're using postgres.railway.internal:5432.
Confirm you're using the current DATABASE_URL and DATABASE_PUBLIC_URL from the PostgreSQL service, as credentials change if the database is recreated.
Try connecting with psql from another service inside the same project. If that also fails, the issue is likely with the database or networking rather than your Node application.
Check the PostgreSQL logs for startup errors, restarts, or connection failures.
If the public proxy and internal endpoint both fail, it's likely an infrastructure issue rather than a pg client configuration problem.
Since you mentioned the public URL worked previously and now neither endpoint works, I'd recommend opening a Railway support ticket with your project ID and database service ID so they can inspect the database proxy and internal network. That will be much faster than continuing to tweak SSL options, as you've already tried the common client-side fixes.