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.

Thanks. We still haven't received a community response, and this issue is now blocking our production integration.

We need an authoritative answer from Railway regarding the API behavior rather than a workaround based on cancelling or deleting a deployment after source connection.

Our requirement is specific: we need to attach a private GitHub repository to a source-less Railway service while deterministically guaranteeing that:

No deployment record is created.

No branch-tip build begins.

Later deployment can be initiated manually using serviceInstanceDeployV2 with an exact reviewed commitSha.

Before serviceConnect, we invoked:

serviceInstanceAutoDeployUpdate(enabled:false)

The mutation succeeded and returned:

enabled:false

We then immediately performed an independently bound read using:

serviceInstanceAutoDeployStatus

for the same project, environment, and service.

That status returned:

enabled:true

Because the mutation result and independent status disagree, we cannot safely treat the mutation response alone as proof that autodeploy is actually suppressed.

We need Railway staff or someone with authoritative knowledge of this contract to clarify:

Is serviceInstanceAutoDeployUpdate(enabled:false) expected to persist and effectively disable autodeploy on a source-less service before a repository is connected?

What exactly does the enabled value returned by serviceInstanceAutoDeployUpdate represent: requested state, persisted configuration, or effective state?

What exactly does serviceInstanceAutoDeployStatus.enabled represent?

Is a false mutation response followed immediately by status enabled:true expected behavior for a source-less service?

Is read-after-write consistency guaranteed for these operations?

Does serviceConnect create or enable a deployment trigger?

Can serviceConnect create an initial deployment record?

Can serviceConnect begin a build automatically from the connected branch?

Is there a supported API or GraphQL operation that attaches a repository without creating any deployment or build?

Is there a supported way to deterministically disable autodeploy before serviceConnect?

Is there an atomic API operation that connects a repository directly into a manual-deploy-only state?

If such a mechanism exists, what are the exact mutation/query names, required inputs, returned fields, and required ordering?

We specifically need a deterministic guarantee of ZERO deployment records and ZERO build execution during source attachment.

Post-connect cancellation, deleting a deployment trigger after connection, or cancelling a deployment after it appears does not satisfy this requirement because an unreviewed deployment/build may already have been created or started.

If Railway's current API does not support this requirement, confirmation of that would also answer our question and allow us to redesign the integration appropriately.

Thank you.