4 months ago
There’s currently three distinct roles for workspace members: Admin, Member, and Deployer. Each role is designed for specific use cases and comes with scoped permissions.
Admin — Full administration of the workspace and all projects. Admins can modify service settings, delete projects, manage billing, add or remove members, and change member roles. This is the role for team leads, engineering managers, and anyone who needs complete control over the workspace.
Member — Access to all workspace projects with the ability to create and configure services, manage variables, create volumes, and create new projects. Members can do everything needed to build and deploy applications, but they can't delete services, volumes, or projects, and they can't manage workspace members or billing. This is the role for most developers on your team.
Deployer — View projects and trigger deployments through commits to repositories via the GitHub integration. Deployers can't use the CLI to deploy, can't modify variables or service settings, and can't view logs. This role is designed for automated systems, CI/CD pipelines, or team members who need to trigger deployments but shouldn't have access to production data or configuration.
What are some other roles/permissions that you would like to be able to configure?
0 Threads mention this feature
5 Replies
4 months ago
Environment based access control would be amazing. Some folks should have access to create/delete services, change/update env vars, etc. in dev or their own personal environments, but shouldn't have access to do that in prod.
4 months ago
I second the previous speaker. I want to give developers permission to modify services and environment variables in the dev environment, but I want to make sure that in the production environment they can only read logs.
4 months ago
Same as above, i want to be able to restrict permissions to my production environment. Not all developers should see env vars, update config, etc
3 months ago
Some things we see as important capabilities:
1. Environment level permissions (granting access differently for different environments)
Control whether a user can access the environment variables in a given environment
More complex, but would be great to have the ability to require approval for any configuration changes in a given environment (maybe this could be implemented if all UI based configs were removed, leaving only railway.config.json, meaning all changes needed to go through CI/CD)
3 months ago
I'd want one set of people to manage the infra, and one set of people to run the app.
A lot of the separation I need is between environments. So the systems team build the infra, the developers write the code, and when it's merged to dev then it gets deployed to that environment and all I want the developers to be able to do in that environment is read the logs, and query the DB.
Then when it comes to deploying to prod, I want to then push the current state of the software in dev (because it's gone through the QA team) into prod. I do this at the moment by creating images in GitHub, storing it in GitHub images, and auto-deploying that image to dev. And then when it comes to deploying to prod, I manually update the image that the container is using to the one that should be deployed. This makes rollbacks super easy too, because if there's an issue, you just deploy the old image.
I want the deploy team to be able to do that in prod (edit the image currently, but it would be nice to have a better way to do this), but not edit anything else.
And then again, I want the whole team to be able to view logs for troubleshooting, but that's it. No access to prod DB.
So that's:
Systems people manage infra
Deployers manage prod deploys
Developers push code which is auto-deployed to dev, and can view logs everywhere and access dev DB
This is effectively my current AWS setup on a bunch of projects, where CodeDeploy/CodePipeline make this easier to manage and share the ECR image across accounts. I have to pass security audits, and auditors love the fact that infra is locked down to specific people, that prod deploys are locked down, that nobody can view anything they shouldn't or get something into prod that didn't go through a process (starting with github reviews). I can almost approximate it with Railway, but it's not easy.