14 days ago
Hi,
Lately I am having a lot of problems with my workspace. To be honest, this will be my last try to get help, otherwise I will move to another platform.
Today, everything was working fine in the production environment. Then I decided to create a staging environment. Once created/deployed, I got a lot S3 connection errors. Before I didn't had any problems. Don't tell me to check my config because everything is correct as it should be.
In the production environment, I checked the environments with "env" and I saw that it used the credentials of staging. Then I deleted the staging environment, and checked again, but it still doesn't work.
When I ask the AI agent something, it can't find the bucket but all other services it can reach. So something went wrong here. I need to fix this ASAP because currently my production environment is offline.
And another stupid thing is that whenever I change the service/app names in staging environment, it also gets changed in production env. What a stupid way of changing names.
Anyway, I am very frustrated. I like the UI of this platform, but the UX sucks.
And I also can't select the stupid S3 service because it's not showing up in the list for this thread.
1 Replies
14 days ago
This thread has been opened as a public bounty so the community can help solve it. The thread and any further activity are now visible to everyone.
Status changed to Open Railway • 14 days ago
13 days ago
This is recoverable — it's a Railway behavior, not a broken project, and your app config is probably fine. The issue is a Railway-level value that changed silently when you set up staging.
What happened: Shared variables in Railway are project-wide, not per-environment. If your S3 creds/bucket are shared variables (or production references them via ${{shared.…}}), then configuring them for staging overwrote them for the whole project — production included. That's why env in production now shows staging's credentials. And deleting the staging environment doesn't undo it: shared variables aren't owned by the environment, so the staging values are still sitting there and production is still reading them. Every other service works because those resolve via references that still point correctly — only the S3 bucket/creds got overwritten, which is exactly why the agent reaches everything except the bucket.
Fix (get prod back up):
- Switch to the production environment.
- Open Shared Variables (project settings) and the S3 service's Variables tab — you'll see the staging values there.
- Restore the production S3 values. If the originals were overwritten and aren't recoverable in the dashboard, re-enter them from AWS / your secrets store.
- Deploy the staged change — variable edits stage and don't apply until you deploy. This step is easy to miss.
To prevent a repeat: keep production values as a production environment override, and when you rebuild staging, set the staging bucket as a staging-only override — don't edit the shared value to a staging value again.
On the renaming: that's expected, not a bug. A service is one project-level entity shared across environments, so its name is shared too — renaming in staging renames it in production. If you truly need different names per environment, use two separate projects instead of two environments.
Start at step 2 — once you see the staging values sitting in production's variables, the rest follows, and step 4 is what actually brings prod back.