Title: Does clearing a custom Config File Path trigger a deployment during Config as Code → IaC migration? We are preparing to migrate three production services—worker, API, and frontend—from legacy Config as Code files to Railway Infrastructure as Code. The services currently use these custom Config File Paths: * `/deploy/railway/worker.json` * `/deploy/railway/api.json` * `/deploy/railway/frontend.json` The equivalent build and deploy settings are already represented in the project’s canonical `.railway/railway.ts`. Environment and tooling: * Production environment * Railway CLI `5.44.1` * Railway SDK dependency `railway@3.11.0` * GitHub auto-deploy disabled for all three services Both human-readable and JSON IaC plans currently return: * `0 add` * `0 change` * `0 delete` * `changes=[]` * `diagnostics=[]` * no staged patch * no deployment ID * no ownership, overlap, migration, or deprecation warning The legacy JSON files and IaC definitions have also been checked field by field and are semantically aligned. Before modifying production, we need to understand the exact platform behavior: 1. Does clearing a custom Config File Path in the service settings immediately create, stage, apply, or trigger a deployment or restart? 2. If it creates only a staged change, which action commits the cleared field? Can that setting be committed without deploying or restarting the currently running service? 3. After clearing the Config File Path, is `railway config apply` required to transfer management to IaC when `railway config plan` still returns `0/0/0`? 4. Can applying an empty `0/0/0` IaC plan create deployments or restart any existing service? 5. Does disabling GitHub auto-deploy protect only against Git-triggered deployments, or also against deployment effects caused by service-setting changes? 6. Is it expected that `railway config plan` reports no ownership or overlap diagnostic while custom Config File Paths are still configured? 7. Is clearing and validating one service at a time—worker, API, then frontend—the recommended lowest-risk sequence? We specifically need to distinguish between: * editing a service setting, * creating a staged project change, * applying that change, * and triggering an actual service deployment. No production setting has been changed and no IaC apply has been performed.

Clarification required before migrating production services from custom Config File Paths to Railway IaC

omerfgedik

PROOP

a month ago

Title: Does clearing a custom Config File Path trigger a deployment during Config as Code → IaC migration?

We are preparing to migrate three production services—worker, API, and frontend—from legacy Config as Code files to Railway Infrastructure as Code.

The services currently use these custom Config File Paths:

/deploy/railway/worker.json
/deploy/railway/api.json
/deploy/railway/frontend.json

The equivalent build and deploy settings are already represented in the project’s canonical .railway/railway.ts.

Environment and tooling:

Production environment
Railway CLI 5.44.1
Railway SDK dependency railway@3.11.0
GitHub auto-deploy disabled for all three services

Both human-readable and JSON IaC plans currently return:

0 add
0 change
0 delete
changes=[]
diagnostics=[]
no staged patch
no deployment ID
no ownership, overlap, migration, or deprecation warning

The legacy JSON files and IaC definitions have also been checked field by field and are semantically aligned.

Before modifying production, we need to understand the exact platform behavior:

Does clearing a custom Config File Path in the service settings immediately create, stage, apply, or trigger a deployment or restart?
If it creates only a staged change, which action commits the cleared field? Can that setting be committed without deploying or restarting the currently running service?
After clearing the Config File Path, is railway config apply required to transfer management to IaC when railway config plan still returns 0/0/0?
Can applying an empty 0/0/0 IaC plan create deployments or restart any existing service?
Does disabling GitHub auto-deploy protect only against Git-triggered deployments, or also against deployment effects caused by service-setting changes?
Is it expected that railway config plan reports no ownership or overlap diagnostic while custom Config File Paths are still configured?
Is clearing and validating one service at a time—worker, API, then frontend—the recommended lowest-risk sequence?

We specifically need to distinguish between:

editing a service setting,
creating a staged project change,
applying that change,
and triggering an actual service deployment.

No production setting has been changed and no IaC apply has been performed.

$20 Bounty

3 Replies

Railway

BOT

a month ago

This is a question the Railway community is better placed to answer than support: people who have already worked this out on their own projects and can tell you what actually worked.

So we'd like to open your thread as a community bounty. Railway pays a bounty to the community member who answers it, and threads like this usually get picked up quickly.

Opening it makes this entire thread public, including everything already posted. Nothing becomes public until you decide. Use the buttons below.

Open to the community - Before you click, take a moment to edit or remove anything you'd rather not share. The thread becomes publicly visible right away.
Keep it private and close the thread - Nothing becomes public and the thread closes.

Status changed to Awaiting User Response Railway • about 1 month ago

Railway

This is a question the Railway community is better placed to answer than support: people who have already worked this out on their own projects and can tell you what actually worked. So we'd like to open your thread as a community [bounty](https://docs.railway.com/community/bounties). Railway pays a bounty to the community member who answers it, and threads like this usually get picked up quickly. **Opening it makes this entire thread public**, including everything already posted. Nothing becomes public until you decide. Use the buttons below. - **Open to the community** - Before you click, take a moment to edit or remove anything you'd rather not share. The thread becomes publicly visible right away. - **Keep it private and close the thread** - Nothing becomes public and the thread closes.

omerfgedik

PROOP

a month ago

Thank you, but I still need clarification from Railway support or the relevant product/engineering team.

This is not a request for community migration experience or general best practices. It concerns the guaranteed behavior of Railway’s current production platform and IaC tooling—specifically whether clearing a custom Config File Path stages or triggers a deployment/restart, and whether an empty 0/0/0 IaC apply is required to transfer configuration ownership.

Community anecdotes cannot establish these production side effects with sufficient certainty. Please keep this thread private and escalate the questions in the original post to a human support or product/engineering representative.

We will not modify the production services until Railway provides authoritative clarification.

Status changed to Awaiting Railway Response Railway • about 1 month ago

Railway

BOT

a month ago

This is still a question the community is better placed to answer than support. The buttons below are still live: open the thread up as a public bounty after editing out anything sensitive, or keep it private and close it.

Status changed to Awaiting User Response Railway • about 1 month ago

Railway

BOT

a month ago

This thread has been opened as a public bounty so the community can help solve it. The thread and any further activity are now visible to everyone.

Status changed to Open Railway • about 1 month ago

Welcome!