2 months ago
We have a reasonably complex CI system and the managed railway deployments isn't cutting it for us anymore, mostly due to race conditions. I have built a solid workflow that creates new environments that we can use for deployments, but the problem is that these automatically spin up every service in our railway stack which we don't want. Also, they're made in the same section as our main production and development environments which is pretty bad for organization.
The ideal workflow would be:
- Create a PR environment using the CLI.
- Deploy services manually using CLI as needed.
This guide: https://docs.railway.com/guides/github-actions-pr-environment does not help here because the new environments automatically launch all the services in our stack which we explicitly do not want nor need.
0 Threads mention this feature
3 Replies
2 months ago
This thread is a duplicate of Is there a way to create PR environments via the CLI?. Closing this one.
Status changed to Duplicate Railway • 2 months ago
2 months ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 2 months ago
2 months ago
Hi wuguishifu,To address your goal of a custom, race-condition-free workflow, it is important to clarify a couple of things about the current CLI and platform behavior:CLI Limitations: There is no single native command to "create a PR environment" that behaves exactly like the managed feature (with automated teardown). railway environment new will create a persistent environment, not an ephemeral one.The "Full Stack" Issue: You mentioned that Railway spins up every service. If you are using the managed "PR Environments" feature, you can significantly mitigate this by enabling Focused PR Environments in your Project Settings. This allows you to define "watch paths" so that Railway only deploys the services actually affected by changes in the PR, rather than your entire stack. If you want to build a custom CI workflow:Instead of trying to trigger managed "PR Environments" via CLI (which isn't designed for partial service deployment), many teams with complex CI requirements adopt this approach:Programmatic Environment Creation: Use the Railway GraphQL API rather than the CLI. You can script the creation of a new environment and then use the API to deploy specific service IDs to that environment.Targeted CLI Deployment: If you are managing the environment creation yourself, you can use the CLI to deploy specific services into that new environment using:railway up --service --environment Custom Teardown: Since you are handling the environment lifecycle in your CI script, you can include a railway environment delete step in your CI's "post-merge" or "failure" cleanup logic.Recommendation: If the "Managed" PR feature isn't working for your specific race conditions, the most robust path is to use the GraphQL API to manage the lifecycle of your environments, and use the CLI purely for the targeted railway up deployments of specific services.
a month ago
Piling on here, I really want this functionality in the CLI. Otherwise the environments get very cluttered and expensive as we have many concurrent PRs and some are trivial and do not need environments.
a month ago
May I suggest a feature where you (Railway) spin up the managed environments IFF the PR has a specific label? that way we could just add a label to get a managed environment spun up for the PR. No label, no managed environment.