Hello, writer of that guide here.

This is a known limitation, for a few reasons.

Across all environments within any project -

• The private domains on services can be the same.

• The private network's DNS resolver is the same address.

• The subnet is the same.

All these factors combined mean you can only run one subnet router at a time in any project, since there is no way for tailscale to differentiate.

I don't currently know of any workarounds to let you run multiple subnet routers at the same time short of writing my own tunnel built into the CLI.

I see. I don’t know if there are plans to change any of the above, but if not then it would be useful if a subnet router could allow access to all the services in the same project, rather than limit them by environment. Thanks!

The private network itself is scoped a given environment, so this would not be achievable unfortunately.

Would you mind sharing your use case, perhaps there is an alternative solution?

I’d rather have all non-user-facing services off the publicly available internet. Web apps would connect to them via the private network only, and I would still need to connect to them somehow, for debugging, backup etc. so Tailscale seemed like a good solution.

I guess a way of achieving what I’m describing would be to let go of Railway’s notion of environments, and instead deploying all of my services in a single env.

Does this work if you take a specific subnet router offline? e.g. if you want to access the services within the staging env, take the subnet router in the production env offline.

Yeah, that works too.

Putting both staging and production on the same “environment” would make the PR Environment feature unusable.

Yeah unfortunately that's the best solution we can offer right now - keeping only one subnet router running across your entire railway account at any given point.