I was asked to copy this here from Discord:

9/12/26, 8:19 PM

I tried experimenting with railway IaC since I see what I was previously using without issue (Config-as-Code) was being has been deprecated.

Tested on CLI 5.49.2, including a fresh project. Routine service additions, updates, and removals worked; these issues remained:

• Invalid generated TypeScript: config pull emitted duplicate declarations for a repository and service sharing a name, causing the untouched export to fail planning.
• Migration path resolution: config migrate treated /frontend/railway.json as an absolute filesystem path and reported it missing, although frontend/railway.json existed in the repo.
• Inconsistent cross-environment identity: redis("cache") failed in a second environment because the name already existed in the project, while ordinary services reused their identities successfully. Separate database names work around this.
• Plan misses a predictable failure: The database-name conflict above passed planning as a safe creation and surfaced only during apply.
• Redis reconciliation mismatch: A Redis image declared through service(...) applied successfully, but an unchanged plan proposed deleting a database and creating a service. Using redis(...) produced no changes.
• Misleading JSON success: Failed applies returned top-level "ok": true; the failure and diagnostic appeared only inside applyResult.
• One thing I liked about the Config-as-Code was that it was a Railway-executed config and very simply configurable per repo. IaC requires a user-created and maintained workflow for applying changes.
• Most of my environments / projects are multi-repo. This IaC config seems to prefer monorepo and calls having config in separate repos (named partials) a "last resort".
• To clarify, I would prefer something like partials as a first class construct instead of "last resort"

---

New additions (Oct 2):

One additional problem, which exists for any "self-applied" IaC: you can erase and break things trivially. Agents exponentially increase the risk associated with this. It's like putting a "nuke everything" button beside the enter button. It's just a matter of time before an accident happens.

In the old config-as-code, all changes had to go through github and review and were trivially scoped to the repo and / or code that was associated with them. This meant that you could delay a change getting to prod trivially by not merging the release branch. With proper github guardrails, this makes it nearly impossible for agents to modify config in railway accidentally (obviously still possible with the CLI, but it is harder to break things at scale). To use IaC safely, I basically have to ensure all my agents everywhere don't have access to the railway CLI and only wait for a plan on PRs to verify their infra changes. That's not an ideal development workflow.

"@therobotcarlson", you say, "surely you can just use our github action to plan and apply your IaC safely?"

The railway github action doesn't understand different deploy environments. It uses a railway token, which is scoped to only a specific environment. So every person that has a dev and prod split can't use railway's action. (Or have to figure out environment-scoped secrets in github)

What about long lived feature branch deployments with infra changes? You can't iterate on infra changes in a fresh env without making and adding new railway tokens to github?

All that said, I love the idea, I just wish it had more time to bake as optional before forcibly removing something that worked and replacing it with something not equivalent: worse in some regards, better in others.

Idealized model:

• Each repo defines its own IaC - this is possible through named partials now. (orgs who separate their IaC into specialized infra repos are living in the past, but monorepos are a different kind of ick)
• Railway applies that IaC from a commit. Does this look like a separate service? Maybe? An env config? Either way, somewhere I say, "I have IaC I want to deploy from this repo" and then I add another repo with more IaC that can all live in the same environment and is ONLY applied to that environment. The impact is scoped. If I merge a PR, it should only be able to nuke one environment at a time.
• A railway app that comments the plan diffs on PRs. Charge us for the compute if you must. Railway is already linked to my github and can make PRs. Railway has permission already.