Hi, this feature cannot be disabled.

As long as someone on the team has access to the repo, they can approve deployments. You can also invite the collaborator to your team.

I'd like to be able to disable this too. We have external contractors committing code I want to deploy automatically (eg in branches), but I don't want to give them access to railway.

The contractors would need to have Railway accounts with their GitHub accounts linked then you add them as viewers to your railway project.

This is also causing big problems for my agency. We've been rolling the basic plan, with a limit of 3 collaborators per project. Upgrading each project would be costly and it would be tedious to invite and manage every collaborator. I'd expect some way to circumvent this feature. Is it possible to approve deployments using the CLI for instance? Can I trigger an authorized deployment via a Github action?

The contractors would need to have Railway accounts with their GitHub accounts linked then you add them as viewers to your railway project.

Does that mean they have Railway access which means they could access secrets etc stored per account/service?

Does that mean they have Railway access which means they could access secrets etc stored per account/service?

For now, yes. We're working on shipping variable sealing [0] that allows you to permanently prevent a variable from being read by anyone

[0] https://railway.app/changelog/2024-09-06-edge-improvements#rbac-is-coming

How about you also just support the option of disabling the Needs Approval requirement?

We have this in place to prevent anyone with repository access from having infrastructure access; the latter should be separate from a security perspective. It's a definite UX regression so we're looking at ways we can make this easier, but unfortunately disabling it outright isn't in our books right now (just to set some expectations)

Are there other considerations you have besides access controls for secrets?

"We have this in place to prevent anyone with repository access from having infrastructure access; the latter should be separate from a security perspective."

And your solution is if we want code to auto-deploy then we give them infrastructure access? Giving external developers MORE infrastructure access seems to go against security best practice.

We already prevent anyone with repository access from having infrastructure access, through github branch protection. Branches that we need to review before being deployed by Railway are protected so that unapproved developers cannot commit to these branches.

Considerations: How can we spin up testing infrastructure (eg in a specific development branch) that auto deploys, without giving these developers infrastructure access?

And your solution is if we want code to auto-deploy then we give them infrastructure access? Giving external developers MORE infrastructure access seems to go against security best practice.

We've just rolled out the ability to prevent people from seeing critical secrets as part of sealed variables. And this is not "more access". They are inherently getting less access because they can't access the envvars they could previously

If you have specific role based access needs, we're happy to chat about those. We're actively working on building this out based on user needs.

Considerations: How can we spin up testing infrastructure (eg in a specific development branch) that auto deploys, without giving these developers infrastructure access?

Test fixtures make copies of existing stacks and as a result can leak secure envvars to those contractors. These changes are in place to prevent this from happening

This is also causing big problems for my agency. We've been rolling the basic plan, with a limit of 3 collaborators per project. Upgrading each project would be costly and it would be tedious to invite and manage every collaborator. I'd expect some way to circumvent this feature. Is it possible to approve deployments using the CLI for instance? Can I trigger an authorized deployment via a Github action?

This is the exact usecase we've designed "Teams" around. Could you let us know how where this isn't working?

Can you please explain to me how giving additional people access to my railway account is not "more access"?

No/Zero access to my railway account (previous config): No access.

Having to invite a user to my railway account: More access than no access.

I just want the feature to be optional.

Can you please explain to me how giving additional people access to my railway account is not "more access"?

No/Zero access to my railway account (previous config): No access.

Having to invite a user to my railway account: More access than no access.

I just want the feature to be optional.

I had the exactly same issue, and I don't want to add any other developers to Railway team. Requiring people to have access to Railway account and then rolling out features like hiding envvars from them does not make any sense to me.

Please add this feature. Classic case of a client telling you exactly what they want that are paying and you explaining why we don't want it just aggravating everyone for no reason.

Any update on this please? We have had a developer leave us and I've had to go through and rotate ALL the environment secrets because they had access to view all secrets because you forced me to give them access to Railway so deployments would proceed.

Hello!

Previously in this thread we shared that you could add users to the project with the viewer roll so that they would not have access to the variables, or alternatively you could have sealed the variables, could you share your thoughts on why these options weren't considered?

I want to be able to view the variables myself, so I don't want to seal them. I also don't think you can seal Shared Variables in the project settings.

Deployer role looks like it costs me $20 a month per developer. Adding a Project Member doesn't give me the option of a deployer role.

I still don't understand why you don't give us what we want, the ability to auto-deploy all commits regardless of whether it's a railway user or not. Ie what it used to be. Could you share your thoughts on why this option wasn't considered?

I will let others answer that last question as I was not personally involved in that project.

As for the deployer role, it does cost $20 /m.

Instead, the viewer role is a role available when you add members to the project and project members do not have additional costs.

Try these screenshots.

The overall People page supports Deployer role, but costs $20 each.

The Team members doesn't give me Deployer role options.

https://imgur.com/a/37NacOn

Appreciate you looking into this.

Terribly sorry, I had it mixed up, I was thinking about the viewer role for project membership.

The deployer role for team members does indeed cost $20.

I've updated my previous correspondence.

So how can I automate deployments for my developers without giving them access to view secrets (without blocking myself from those secrets) and without paying $20 each?

Are you able to add the deployer role to when we add members to the project? Rather than just View and Edit please?

Instead of them saying honestly this doesn’t work for their revenue model they just keep beating around the bush with with excuses. It’s super annoying and a huge flaw. If anything they should allow at least all dev branches to skip this feature.

So how can I automate deployments for my developers without giving them access to view secrets (without blocking myself from those secrets) and without paying $20 each?

You can use the CLI for this if you'd like. Simply create a Railway account, generate a token, and then setup the CI/CD workflow to deploy from there using the token

Instead of them saying honestly this doesn’t work for their revenue model they just keep beating around the bush with with excuses. It’s super annoying and a huge flaw. If anything they should allow at least all dev branches to skip this feature.

I think we were pretty clear with our revenue model no? The Pro model is $20/seats. The goal of having your team on Railway is to manage access control. That's what we've rolled out with the Deployer role; a role where you can say "This user is restricted and cannot view environment variables"

Hi Jake!

Thanks for providing constructive advice. I've felt quite rejected by the Railway team on this matter so far..

We've been considering using the CLI for automating deployments but I would like some clarity in whether this will have continued support. I suggested this in another thread a couple months ago and
I was not left with enough confidence.

Do you have any insight into the current situation? Can I rely on the CLI to continue support using a token?

Hey! The CLI is load bearing for a lot of clients and will 100% be supported. We're all in on the cli. We even own the cli.new domain name

Hope that answers the question but if not let me know!

You can use the CLI for this if you'd like. Simply create a Railway account, generate a token, and then setup the CI/CD workflow to deploy from there using the token

Do you have any documentation around this? Do we just run railway up ?

One of my favourite things about Railway (until a few months ago) was the ability to just link to a git repo, and it could be configured to auto-deploy my code on commits. Simple and effective without my manual intervention each time. No complicated deployment setup. This has now changed for the worse.

Instead of them saying honestly this doesn’t work for their revenue model they just keep beating around the bush with with excuses. It’s super annoying and a huge flaw. If anything they should allow at least all dev branches to skip this feature.

I think we were pretty clear with our revenue model no? The Pro model is $20/seats. The goal of having your team on Railway is to manage access control. That's what we've rolled out with the Deployer role; a role where you can say "This user is restricted and cannot view environment variables"

My interpretation of a 'seat' is a user that has access to Railway to manage infrastructure. Not "$20 per person that commits to my repo".

As I've said many times before, I don't need or want Railway to manage my access control. I already do that with github branch protection. I don't need another layer of complexity.

We can all see what you're doing, you're forcing us to add users that cost an extra $20 per person, even though they never touch anything in Railway.

If you genuinely wanted to "manage access control" you would make the deployer role a free account, and/or add the deployer role option to the free user in the Project settings page. Or make it an optional feature.

This whole thing just leave a massive sour taste in my mouth, all over $20.

As I've said many times before, I don't need or want Railway to manage my access control. I already do that with github branch protection. I don't need another layer of complexity.

How would you solve the issue of someone creating a pull request against your repo and then getting access to the secrets?

We do the exact same thing GitHub does here in terms of "authorizing deployments" so that you can make sure that nobody gets around the access control

If you genuinely wanted to "manage access control" you would make the deployer role a free account, and/or add the deployer role option to the free user in the Project settings page. Or make it an optional feature.

Yea we're talking about that internally already. It exposes a layer of complexity in terms of "What seats do you charge for?" and additionally about "Well, what about deploying PR environments?" which again, brings us back to the current solution

Ideally I'd like to just remove the costs of seats at all so this is a non-issue. The goal is to get everyone on your team on Railway in some way shape or form.

This whole thing just leave a massive sour taste in my mouth, all over $20.

Really sorry about that. I see your spend is pretty reasonable anyways on the platform, so I'm gonna go ahead and waive the per seat cost entirely for the Elixir team

BTW thank you for engaging . Really appreciate the feedback and agree this needs to be better and we're working on it

That said, there's added complexity that comes with "Just let me disable the feature" and "Only charge for these kinds of seats"

As I've said many times before, I don't need or want Railway to manage my access control. I already do that with github branch protection. I don't need another layer of complexity.

How would you solve the issue of someone creating a pull request against your repo and then getting access to the secrets?

Do you mean if they committed code that printed all secrets?

1. I don't have PR environments enabled

2. If I did, I'd configure it to use a test environment that didn't have secrets that I cared about.

Ideally I'd like to just remove the costs of seats at all so this is a non-issue. The goal is to get everyone on your team on Railway in some way shape or form.

This whole thing just leave a massive sour taste in my mouth, all over $20.

Really sorry about that. I see your spend is pretty reasonable anyways on the platform, so I'm gonna go ahead and waive the per seat cost entirely for your team

Thank you, I really appreciate it. I think this is a reasonable compromise if you're able to give enough granular access control so they can only see what I want them to see.

Having developers with some view access is nice so they can view logs without seeing/accessing secrets.

Do you mean if they committed code that printed all secrets?

1. I don't have PR environments enabled

2. If I did, I'd configure it to use a test environment that didn't have secrets that I cared about.

Yea basically if they just fork your code and say "Yea print all variables"

Or say, if someone's configured their repo to be enabled with Railway's deployments, and then you boot them from the org.

They could still have triggers wired up which could leak secrets by creating deploys which auto deploy from the above

"Needs approval" aims to solve these threat vectors. I recognize that we've added more friction here and for that I'm truly sorry. I pushed a thread earlier about how we dont' love this feature 100% yet and much of the team agreed.

Thank you, I really appreciate it. I think this is a reasonable compromise if you're able to give enough granular access control so they can only see what I want them to see.

Having developers with some view access is nice so they can view logs without seeing/accessing secrets.

Yup. And like, in an ideal world, you can define these permission structures because it'll be a "different strokes for different folks" type scenario

But obviously we're not there yet if this features still causing this much friction, so I'd like to fix that before we move onto anything more complex

BTW my proposed solutions here would be:

Maintaining a list of "Approved contributors", which are basically pending invites to the team. If those users go and make Railway accounts and USE those permissions, they'd be active on the platform. Otherwise you wouldn't pay for them but they'd be approved to deploy.

This way instead of you having to invite them, create an account, etc, you 1-Click an action and all their deploys work and you only pay for a seat if they're actually USING Railway's features

Thoughts?

I see what you're saying, but it does feel convoluted. I don't love it.

Giving my staff access to only deploy + view logs without making changes (or viewing secrets) is very useful to me. Ie the deployer role is great!

Why do you charge per seat at all? Why don't you just have a minimum spend each month per plan?

Why do you charge per seat at all? Why don't you just have a minimum spend each month per plan?

Honest answer: because I made a dumb call like 2 years ago to do it and we've prioritized building actual features (baremetal, multiregion, etc) over billing features (stuff like this)

And it's been easier to, for anybody who complains about this but has sufficient spend, just say "Alright fuck it we'll just waive the seats"

Hahaha love the honesty. I can relate to the same process myself.

Just mentioning this again, for us, we regularly outsource contractors or freelancers and it makes it hard when I have to check this myself every day to see if there are new merges to dev or main that I need to approve. For us it doesnt make sense to have everyone in the team. We have loads of part time developers our github rules cover what matters and leaking production secrets would take someone approving a bad pr to dev and then approving it to main its just not likely to happen.

I have to agree with above in it feeling like the $20 per seat restriction is the cause of this decision.

You could create another service "B" inside the project that connects to the webhook of the service "A", and receive a message on the "NEEDS_APPROVAL" type alongside the deployment number that is attached with the payload, and automatically performa gql operation with an api token using the public api to approve that specific deployment for "A".
With this you basically disable the needs approval feature

Something like this