a month ago
Hi There,
This is a compliance related question on the way workspaces work. In my account I have multiple workspaces. Each workspace has multiple projects. If I invite another user into the workspace or transfer the ownership of the workspace to third-party (or client), will they be able to access/connect all the repo my account (the original developer) had originally given the permissions on? As per the architecture, What is the relationship between github account connections and Railway Users and the workspace and the project? will the new user able to deploy any apps or access the source code through anyone other workspace user's github repository access?
Please clarify this access relationship on the codebases. (see screenshot below)
Attachments
2 Replies
a month ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • about 1 month ago
a month ago
Railway workspace/project access and GitHub authorization are separate, but a member may still be able to deploy a service whose source is connected through another member's GitHub authorization.
Please do those:
- Review the GitHub App's repository permissions and restrict it to only required repositories.
- Review each project's members and use the minimum Railway role required.
- Verify whether a workspace member can deploy/reconnect a repository that is authorized only through another member's GitHub account.
- Before transferring the workspace, audit all GitHub connections and project source bindings.
Let me know the results.
an hour ago
Short answer: invited users can't read your repo's code through Railway, but they can deploy from it — so treat workspace membership as trust.
- The GitHub link belongs to the Railway user who connected it, via the Railway GitHub App installation they authorized. It's per-user, not per-workspace — Railway does not hand your code to other members.
- Other workspace members can see the service, trigger redeploys, and read deploy logs (which can contain file paths). Keep secrets out of logs and build output regardless.
- If the person who linked the repo leaves or revokes GitHub access, autodeploys break for everyone — the usual surprise. Re-link from a current admin account to fix.
- To lock it down: GitHub → Settings → Applications → Railway → restrict it to only the repos it needs; keep production projects in a workspace with the minimum members.
- On project transfer between workspaces/accounts: the old owner's GitHub authorization does not travel with the project — re-verify the GitHub connection in the new workspace or deploys will silently stop.