This appears to be an issue with the way your n8n is connecting to your database

Please go into the variables and change the:

• QUEUE_BULL_REDIS_HOST from ${{Redis.REDISHOST}} to ${{Redis.REDISHOST_PRIVATE}}

• QUEUE_BULL_REDIS_PORT from ${{Redis.REDISPORT}} to ${{Redis.REDISPORT_PRIVATE}}

For both the Worker and Primary

Many thanks!
I did the changes and when access the application n8n

This message is shown in the browser.

Cannot GET /

What migth be happen?

Many thanks!

Jóse

I have the same exact issue

Connection lost

You have a connection issue or the server is down.
n8n should reconnect automatically once the issue is resolved.

I did the installation several times and even with different templates but anything resolved the problem.

---

did you solve it? I didn't modify anything in the services, but today this issue appeared and now I can't do anything on n8n, and I'm also honestly scared to lost all the workflows, which would be a tragedy, and unexpected (because if I would know that some kind of issue can happen on railway, I would never built my business on it)

Unfortunatelly I am still with the same problem. ;(

to be honest I think this situation is absurd. I've always loved railway, but what's happening today is really weird and we still no have any answer from the support. I can't built a business here, if a day, in a literally casual moment, the n8n service stops to work correctly without any apparently reason, and still no asnwer about the issue after 8 hours. my clients have their workflows that are not working and I'm literally really scared to not recover the JSON of my workflow which would be a damage of thousands of $ for me

Hello,

Since you're self-hosting n8n on Railway, you're responsible for configuring and maintaining your n8n instances. Railway provides the infrastructure, but we don't manage or provide support for third-party applications like n8n.

I've converted both of your threads into community bounties so other users familiar with n8n can help troubleshoot this connection issue.

Best,

Brody

hello, since the service is on railway, and I didn't modify anything, and from today there is this connection issue, I suppose is a railway issue, no? I'm having a big damage and I still don't know the reason. Can you please give me a real solution? I can also upgrade to pro without any problem (it was on my plan, since the last month I spent 30$, so more than the 20$ of the pro plan, and to be honest I have the plan to subscribe for the enterprise plan)

I'm asking you please how to solve, because I'm literally desperate, I have all my workflow inside the servie and I can't lose them

I solved. You should delete the user and create it again, and yu have to do it using railway CLI. if you want I can explain to you, but please mark this message as solution so at least I get the 10 bucks for all the time wasted to solve this unexpected issue ahah

please explain how to do it

After a manual redeploy, my public URLs were not set explicitly. n8n was running behind Railway’s proxy (public HTTPS on 443, app listening on 5678), but the editor/push service was computing the wrong expected origin. That made the push channel (WS/SSE) fail and the UI showed Connection lost. This is a known behavior with recent n8n versions that enforce strict origin checks behind proxies/CDNs.

What fixed it: set the actual public URL and proxy hints explicitly (no placeholders), then redeploy Primary and Worker:

N8N_EDITOR_BASE_URL=https://.up.railway.app
WEBHOOK_URL=https://.up.railway.app
N8N_HOST=.up.railway.app
N8N_PROTOCOL=https
N8N_PROXY_HOPS=1
PORT=5678 (don’t force N8N_PORT=443)

After this, opening workflows worked normally (no more Connection lost). The reasoning matches the docs for reverse proxy webhook/editor URLs and proxy hops.

Optional stability tweaks: if your environment filters WebSockets, set the push backend explicitly and redeploy: N8N_PUSH_BACKEND=sse (or websocket if SSE is the problem). Recent versions default to WS; choosing SSE/WS manually often resolves editor connectivity in proxied setups. Keep N8N_SECURE_COOKIE=true on HTTPS; if debugging odd session behavior through a proxy chain, you can temporarily toggle it to isolate cookie issues, then turn it back on.

How I got back in (if you’re locked out): first make a quick backup from the CLI:

n8n export:workflow --all --output=/tmp/workflows.json
n8n export:credentials --all --output=/tmp/credentials.json

Then reset User Management (this does not delete workflows; it only removes user accounts so you can run the setup again):

n8n user-management:reset

Redeploy, create a new owner account, and all workflows remain intact.

Why this happens behind proxies: n8n builds public URLs from N8N_PROTOCOL/HOST/PORT, which don’t match reality when the app listens on 5678 internally but is exposed as HTTPS 443 via a proxy. The fix is to manually set the public URLs (WEBHOOK_URL, N8N_EDITOR_BASE_URL) and declare proxy hops so the editor and push endpoints validate the correct Origin.

----

hope I can have the bounty now