It would really open up a lot of use cases for downstream users of our templates to allow "Fork repo and eject on deploy".

For a monorepo template where all services come from one GitHub repo, this option would fork the template repo and point all services in the user's deployment toward their new fork. Then we can configure many more runtime bells and whistles via the template:

• Wait for CI

• Watch paths

• Naming service subdomains for private networking

1 & 2: Coming soon, it's fully supported by the underlying configuration schema, we just need to update the UI.

3: Any reason you don't put variables in one most applicable service and then reference variables from that service in other services?

4: We already support this - https://docs.railway.com/guides/deploy#eject-from-template-repository

5. Not possible, for both public and private domains we do not support specifying the subdomain during their creation since they need to be unique, but this also should not matter when reference variables are used.

Soon!

Love to see it!

It is now live!

3: Some variables truly are meant to live at the project level, and don't really belong to any one service in our mental models. My sense is that shared variables are a valid part of projects; why not also include them in templates? This is def not a blocker on any real functionality though.

We will likely add them at some point, would you mind creating a seperate feedback post for just that feature request?

4: My concern is about default behaviour on template deploy. I think if a user has connected their GitHub and granted consent for all the Railway GH actions and other scopes, then forking the template's source repo and ejecting right away on deployment would be an incredibly useful feature.

My feeling is that it's not enough to offer the option to eject after the fact. Sure, I'll grant you that many templates on Railway offer fully-packaged software, the source code for which a user would never want to add to. Like fully-featured HR software, calendly, etc. But it should be self-evident that there is a vast landscape of software we want to deploy on railway, which requires out-of-the box that we have our own GitHub repo, and we're building new features and taking advantage of Railway's CI/CD from day one. Full-stack apps, startups and the like. We're talking a crucial dimension of developer experience here.

I'm definitely thinking selfishly here, since I'm in the midst of publishing a template geared towards full-stack app development. I'd like to be able to make the pitch to users that once they click that "Deploy On Railway" button, they'll be able to clone their forked repo and begin pushing features to a continuous deployed environment.

I'd really like to see an option to "eject on deploy". Both opt-in, and required. Some types of projects will simply require that the user be managing source code in their own repo, and template deployment flows should offer that configurability. Thanks for your consideration!

Sure I'll create one

5: On the unique hosts problem: I'd imagine that if the program in your infra layer that creates the private network and all the service subdomains already makes them unique by default, it should also be able to ensure uniqueness if a user manually input, say, a single subdomain. It would follow from that, then, that as long as the user doesn't make an error, and they make the subdomains they want/need to configure unique amongst themselves, then the infra provisioner should still be able to ensure uniqueness, filling in the rest of the hosts that weren't manually edited.

The reason this has become an issue for me, is that I'm trying to deploy a service in my template which parses the subdomain of every request. Every request must have a subdomain, since the service parses it and uses it as a tenant ID, a tenant ID that must actually exist in the application. Luckily I only need to run it in single tenant mode, so the fact that the service is given a hostname on the project private network with a subdomain already in it is actually to my advantage. But I need to configure via an ENV var what the single tenant ID is. For example if the service name is "Connection Pooler", then from trial and error I've noticed that Railway will assign the subdomain of "connection-pooler.railway.internal" to the service, and then in the ENV vars I can set TENANT_ID="connection-pooler" and it'll work. But this feels brittle, and I would like to configure that and rest a little easier that I didn't leave the robustness of networking within my project to the process Railway assigns private networking hosts. Hope that makes sense.

We actually used to eject on deploy by default, but very few people wanted that behavior so we made it so that the user must click the button

So please open a separate feedback post for that as well.

I didn't say it wasn't possible outright, but it's not how the template deploy APIs work right now, and adding new APIs for this isn't on the table right now unfortunately.

Again, please use reference variables, you can reference the private or public domain we assign to the service.

https://docs.railway.com/reference/variables#railway-provided-variables