We checked our documentation and it does not cover this yet, so the Railway community is the best place to get a real answer: 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.

Railway's own bot told you the docs do not cover this, so nobody can hand you a documented guarantee on deploymentTriggerDelete. Anyone who does is guessing. Here is what is documented, and it changes where your risk actually sits.

Your exposure is not the delete, it is the changeset. Staged changes are a single batch: clicking Deploy "will deploy all of the changes at once. Any services that are affected will be redeployed." So if your trigger removal lands in the staged changeset alongside whatever is already staged in that environment, the danger is not the removal executing, it is you later applying the whole batch.

That gives you the containment you asked for, and it is documented: holding Alt while clicking Deploy commits the staged changes without triggering a redeploy. Review the changeset first, Details shows a diff of old and new values, and the x beside any individual change discards just that one. Two caveats worth knowing before you rely on it: Alt-Deploy commits everything staged, not only your change, and networking changes are not staged at all, they apply immediately.

On whether the mutation itself stages rather than commits: for CLI config-patching operations Railway documents that "if the environment has unmerged staged changes, the operation is staged instead of committed directly," including deletes. Whether the GraphQL mutation takes that same path is not documented, and I will not assert it.

For the rest, queued-event handling and race conditions, there is no public answer and I would not accept a community one. Two things get you a real one. The public API is the same API that powers the dashboard, so doing the action in the dashboard on a throwaway project and reading the network tab shows you the exact supported mutation rather than a guess at its name. And reproducing your exact state there, orphaned trigger plus a staged environment, settles every one of your questions for your own configuration in minutes without touching production.

One documented thing that does bear on your retry question: Railway says not to assume exactly-once semantics on mutations, and to retry only when you did not receive a response.

Staged changes: https://docs.railway.com/deployments/staged-changes

Public API: https://docs.railway.com/integrations/api

Disconnecting the source via UI doesn't trigger a new deployment. (I just tested it)

That data point is the useful one, and it goes further than it looks. The public API is the same API that powers the dashboard, so whatever mutation the UI fires on disconnect is by definition the supported non-deploying path. Open the network tab while doing that disconnect on a scratch project and you have your answer with a tested result behind it, instead of guessing at a mutation name.

One thing to check first though. You said Settings shows no connected repository, only Connect Source, while metadata still shows the repoTrigger. If that is accurate there may be no Disconnect control for you to click, which is the discrepancy you opened with. Worth confirming the UI path is actually available in your state before planning around it.

A related clarification about the separate Disable control (not Disconnect):

For a GitHub-connected service, Source shows a separate Disable button for automatic deployments, alongside Disconnect. With unrelated staged changes already pending, does clicking Disable take effect immediately without applying, discarding or modifying those pending changes, and without triggering a build, deployment, restart or pre-deploy command? What happens to already queued GitHub deployment events? Which read-only field or UI state confirms that future commits cannot trigger deployments? Please distinguish this Disable action from Disconnect and Alt+Deploy, and identify any exceptions or conditions.

Guidance only: please do not modify any resources or configuration on our behalf or initiate billable work. No account/project identifiers, attachments, logs or business data are included.

Disabling automatic deployments won't create a new deployment. (I tested this as well)

Ben's test covers the deployment half, so here is the part it does not: Disable and Disconnect are two different operations on two different objects, and that matters for your metadata discrepancy.

Disable does not touch the repoTrigger at all. The trigger record itself has no disabled field. Its fields are id, projectId, environmentId, serviceId, provider, repository, branch, checkSuites, validCheckSuites, baseEnvironmentOverrideId. Autodeploy is a separate per service instance flag with its own mutation, serviceInstanceAutoDeployUpdate(input: { projectId, environmentId, serviceId, enabled }). So Disable flips a boolean and leaves your repoTrigger exactly where it is. Disconnect is what removes the source. Alt+Deploy is unrelated to both: it commits whatever is already staged without a redeploy, and it commits all of it.

Your read-only confirmation is a query, not a field on the trigger:

serviceInstanceAutoDeployStatus(projectId: ..., environmentId: ..., serviceId: ...) {
  enabled
  canEnable
  reason
}

I ran that against one of my own GitHub connected services a few minutes ago and got enabled: true, canEnable: true, reason: null. enabled: false is your confirmation that future commits cannot trigger deployments, and reason is where Railway tells you why it cannot be re enabled if that ever applies.

Two things I will not claim. Whether the autodeploy toggle joins an existing staged changeset: it is not part of the service instance config update path, which is what staging covers, but I did not test it against an environment that already had unmerged staged changes, so test that one yourself. And already queued GitHub events: not documented anywhere I can find. The observable is your deployment history, where anything that arrives and does not run shows up under Show Skipped.

Autodeploys: https://docs.railway.com/deployments/github-autodeploys

Thank you for distinguishing Disable from Disconnect and for the observed no-deployment test. We are not treating that test as a guarantee for other states. Could Railway clarify the remaining contract for Disable and its inverse Enable?

1. With unrelated STAGED changes already pending, are both actions immediate and guaranteed not to apply, discard, consume, or modify that pending changeset?
2. Does Disable affect GitHub events already accepted or queued before the toggle, and is there a supported read-only way to establish that none can still build, run pre-deploy, deploy, or restart?
3. Can Enable immediately enqueue the latest commit or replay older events, or does it affect only subsequent commits? Is reverting the toggle possible without an execution side effect?
4. Is serviceInstanceAutoDeployStatus the supported authoritative readback, and are there caveats beyond its enabled state for these questions?

If no such guarantees exist, please state the limitations explicitly. Guidance only: do not change any resources or configuration, perform tests on our behalf, or initiate billable work. This is a generic contract question; no project/service identifiers, repository details, credentials, logs, attachments, payloads, or business data are supplied.

Two of these four have answers in the public API today, and two of them do not and cannot come from anyone but Railway. Taking them in that order, and flagging up front that I do not speak for Railway.

On 4, yes, and more strongly than "supported": serviceInstanceAutoDeployStatus is the only autodeploy readback that exists. I enumerated every field on the Query type just now, and the only two that touch this area at all are deploymentTriggers and serviceInstanceAutoDeployStatus. ServiceInstance itself has no autoDeploy field, so there is no second opinion to cross check against. The caveat you asked for is a real one though: enabled, canEnable and reason carry no descriptions in the schema, so the exact semantics of canEnable and what populates reason are undocumented. You get a boolean you can trust and two fields whose contract is not written down anywhere.

On 2, there is a better read-only observable than the Show Skipped view I pointed you at earlier. DeploymentStatus is an enum and its full set of values is:

BUILDING, CRASHED, DEPLOYING, FAILED, INITIALIZING, NEEDS_APPROVAL,
QUEUED, REMOVED, REMOVING, SKIPPED, SLEEPING, SUCCESS, WAITING

Six of those are non terminal: QUEUED, WAITING, INITIALIZING, BUILDING, DEPLOYING, NEEDS_APPROVAL. So your check for "nothing can still build, run pre-deploy, deploy or restart" is a query over the service instance's deployments asserting that none sits in any of those six. That is a positive assertion about in-flight work rather than an inference from an empty UI panel, and it is the same API the dashboard uses. Note NEEDS_APPROVAL and WAITING in particular, since neither is obvious from the deployment list and both mean something is still pending.

On 1 and 3, I have nothing verifiable and I am not going to guess for you. Whether Disable and Enable join or bypass an existing staged changeset, and whether Enable replays accepted events or only affects subsequent commits, are both statements about internal scheduling behavior. They are not in the schema, not in the docs, and not observable from outside without running the experiment on an environment that already has unmerged staged changes. Railway has to state those, and given the bot opened this thread by saying the docs do not cover it, I would ask for them as a documentation commitment rather than as a forum answer, so the next person does not have to open this thread again.

One practical note on 3 while you wait. If reverting the toggle has to be execution free with certainty, the containment is to not rely on the toggle at all: remove the trigger so there is nothing to replay, and put the source back deliberately when you want it. That trades a reversible boolean for an explicit action, which is the direction you have been pushing on this whole thread anyway.