Allow changing service source in railway environment new

[Milo123459]

This allows changing service source in railway environment new to either a Docker image or a GitHub repo.

If a GitHub repo is provided, a branch must also be provided. No validation is performed on Docker images due to the many forms they can come in (e.g ghcr.io/...., ubuntu, _/node:latest etc.

Examples

railway environment new foo --duplicate bar --service-sources baz github nodejs/node/master - change the source of the service baz to the GitHub repo nodejs/node/master. Note that a branch is required

railway environment new foo --duplicate bar -s baz docker ubuntu:latest - change the source to a docker image of ubuntu:latest

It also works fully interactively:

Screen.Recording.2025-11-26.at.13.48.07.mov

(note that the query for making a new environment seems to be slowing it down so much due to a change introduced waiting for the environment to be actually duplicated).

Validation is also provided for GitHub repos:

[coffee-cup]

I don't really understand the usecase for this functionality. And having it tied to the railway environment new behaviour does not make sense imo. I think this would make more sense as a new command all together. This would keep the commands have a single responsibility instead of a "god" command that can do multiple unrelated things

[Milo123459]

The use case here is so that users can create pseudo PR environments that have services that actually deploy from there PR branch

[hosmelq]

I would like to see this merged. My use case involves deploying pull requests from GitHub Actions by copying the production environment. If the source action is added as its own command, the duplicated one will deploy first with the copied environment branch, and all start-up scripts will run for that branch. I want to deploy the current pull request branch instead.

[coffee-cup]

Thoughts on passing the config as JSON or something? The command railway environment new foo --duplicate bar --service-sources baz github nodejs/node/master is very unclear to me. Like I guess it is okay, but I worry about the complexity that this is adding to the CLI commands. The use case makes sense, but can we solve it in a clearer and more understandable way?

[Milo123459]

What is unclear about the usage that is currently specified? I'm not sure if parsing the config as JSON would be much better though.

[Milo123459]

btw: currently, due to staged changes not being available on the public API, if you change the source & variables for a service it will make 2 deployments. if staged changes were available on the public API, this could be done in one deployment.

[coffee-cup]

Staged changes should be public soon.

Thoughts on not prompting for a service to change the image source for by default? I'm worried about the complexity of this flow if we prompt for every possible thing that could change. Or instead we could have a "Do you want to configure a service" that goes into a subprompt to configure variables or a source image. It would allow us to extend what you can configure when creating a new environment in the future.

[hosmelq]

I believe this won't work in GitHub Actions because the CLI produces an error on a non-TTY. I already faced an issue deleting an environment in Actions because I have 2FA enabled on my account, and the CLI prompts for it.

[Milo123459]

Glad that staged changes will be made public soon!

I like the idea of being able to select what to configure a service. I'm going to add a multi-select for all the options that can be picked, so that more can be added in the future.

[brody192]

hosmelq, that is correct, you cannot non-interactively enter a 2FA code, so destructive actions are not possible in CI flows. This is mentioned in our docs. You would need to manually clean these up after the fact.

[coffee-cup]

Glad that staged changes will be made public soon!

I like the idea of being able to select what to configure a service. I'm going to add a multi-select for all the options that can be picked, so that more can be added in the future.

I should have a PR/demo soon. Ideally any config should be editable for the service (staged or applying right away) for both in an environment and when creating a new environment with environment new. So making it multi-select and supporting any type of option would be awesome

[Milo123459]

I've started working on the multi-select functionality, currently with just service sources & variables. If you want it to be editable for an existing environment (whilst not making a new one), would you want a different command? Maybe railway environment edit?

And when you say any type of option, could you be more specific? The main things I could think of would be public networking stuff (generating domains, adding domains) but that can already be done through the domain command.

[coffee-cup]

railway environment edit makes sense I think.

By any type of option, I mean all build/deploy/networking/source config. For reference, the staged change/environment config schema is available here.

[Milo123459]

Perfect. Have staged changes been made live on the public API? Most of the CLI side work has been done, and I can begin implementing those other options.

[coffee-cup]

Yes it is available. It is not super well documented though. We are using the staged changes and environment config APIs in a new claude code plugin we are working on. We have some docs there

• https://github.com/railwayapp/railway-claude-plugin/blob/main/skills/environment/SKILL.md
• https://github.com/railwayapp/railway-claude-plugin/blob/main/skills/reference/environment-config.md

Hopefully this should be a good start.

For fetching the environment config, we are already doing this in the CLI for the railway dev command https://github.com/railwayapp/cli/blob/master/src/controllers/config/environment.rs. You should be able to reuse those objects

[coffee-cup]

@Milo123459 Can you please let me know what you are going to do with this command for staged changes. I have a few ideas for a railway config command that lets you configure things for the environment but would also support passing a full json object as stdin

[Milo123459]

My current implementation for the environment new command (which can then be used for the edit command) is that you select what you wish to configure in a multi-select, select services for each option, and then it pulls it all together and makes one API call to update all the services.

Also, I think your idea of the config command is pretty similar to mine for railway environment edit.

[coffee-cup]

Yes they sound similar. I'd love if this worked non-interactively too. I'll wait for the environment edit command. My asks/wishes are

• Accepts a full environment config as JSON stdin in non-interactive mode
• Applies the patch right away (likely using the environmentPatchCommit mutation)
• Accepts a --message flag to set the message of the patch
• Accepts something like a --stage flag that just staged the patch and doesn't apply right away
• Accepts optional environment id as flag

I want to be able to do things like

'{ "build": { "buildCommand": "new build command" } }' | railway environment edit --message "does something" --message "..."

[Milo123459]

Yeah, my version works fully non interactively :)

Noted! I'm gonna add this to my TODOs.

[Milo123459]

@coffee-cup has the claude MCP repo been taken down? The links you've sent aren't working anymore.

[Milo123459]

Also- if applying an edit to an existing environment, and there are staged changes that aren't applied, interactively I'll prompt and show the changes and ask for confirmation to merge, but non-interactively should it merge the changes by default or not apply them at all, even the new ones?

I suppose I could also fetch the current changes, remove them, apply the new changes then apply the old changes again in a new patch and not stage those.