3 months 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
3 months 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 • 3 months ago
2 months ago
This behavior is consistent with stale/literal service variables, not with the production bucket itself changing.
Railway creates a separate bucket instance for every environment, with isolated credentials. The official bucket docs state this explicitly:
https://docs.railway.com/storage-buckets#buckets-in-environments
The safest recovery is:
- Switch the dashboard environment selector to production.
- Open the application service (not the bucket) → Variables.
- Remove only the app's stale literal S3 values that belong to staging.
- Recreate them as variable references to the production bucket instance, preferably with the bucket's auto-inject control. If doing it manually, map the names your Node app expects to the bucket references, for example:
AWS_ACCESS_KEY_ID=${{YourBucket.ACCESS_KEY_ID}}AWS_SECRET_ACCESS_KEY=${{YourBucket.SECRET_ACCESS_KEY}}AWS_ENDPOINT_URL=${{YourBucket.ENDPOINT}}AWS_S3_BUCKET_NAME=${{YourBucket.BUCKET}}AWS_DEFAULT_REGION=${{YourBucket.REGION}}
Replace YourBucket with the bucket's actual display name. The current Railway-provided bucket variables are documented here:
https://docs.railway.com/storage-buckets#railway-provided-variables
- Review and deploy the staged variable change to the production app service. Variable edits do not affect the running deployment until the staged changes are deployed:
https://docs.railway.com/variables
- Verify with one
HeadBucket/list operation from the production app. Do not print either access key while checking.
Deleting the staging environment does not rewrite a literal credential already stored on the production app, which explains why deleting staging did not recover it. Do not reset the production bucket credentials unless they were exposed; resetting would invalidate every consumer and create a second outage.
Also, the bucket not appearing in this thread's service picker is a support-UI limitation and is separate from runtime connectivity. A service display-name change appearing across environments is also not proof that credentials crossed; the important state is the environment-scoped service variables and the bucket instance they reference.
If the production app already contains references (not literal values), check that their namespace still points to the intended bucket name after the rename, then redeploy the staged correction.