9 days ago
For the public GraphQL mutation deploymentStop(id), applied to a running
deployment whose service uses restart policy ALWAYS:
-
Does this administratively suppress automatic restart of every replica of that
deployment until a subsequent explicit deployment/restart action? Are host
migration or platform recovery exceptions possible during a finite handover?
-
Which termination signal is delivered, what grace interval applies, and does
RAILWAY_DEPLOYMENT_DRAINING_SECONDSgovern this explicit STOP operation? -
Which authenticated deployment/replica status proves that all processes have
finished terminating? Is the mutation's successful response only an ACK?
-
Which supported read exposes complete replica termination and any queued or
replacement deployment while the service is stopped?
Please distinguish documented guarantees from best effort, and link the relevant
contract or implementation. This concerns explicit deploymentStop, not a normal
replacement deployment, deploymentRemove, or railway down selecting the latest
successful deployment. No customer identifiers, logs or credentials are needed to
answer these semantics questions.
3 Replies
9 days ago
deploymentStop stops the running container but writes no status change: the deployment keeps reporting SUCCESS and its instances keep reporting as running. The mutation's response is not a completion signal, and no deployment or replica status proves that the stopped processes have finished. It does not cause a redeploy on its own. It is still not a guarantee that nothing runs again under that service. Platform-initiated host migrations and maintenance redeploys can recreate the workload on another host, and so can a new deployment triggered by you or your CI. We publish no signal or grace-interval contract specific to deploymentStop.
If you need termination evidence, use deploymentRemove. It deletes routes, sends SIGTERM, escalates to SIGKILL once the draining period ends, then removes the container. The draining period is set per service through RAILWAY_DEPLOYMENT_DRAINING_SECONDS, service settings or railway.json, and defaults to 0. Removing the container ends every process inside it. The deployment moves to REMOVING and then REMOVED, and its instances follow, all readable through the public deployment / deployments queries. REMOVED is written only after teardown completes for every replica, so it is ordered evidence. One caveat: if the host is already gone, REMOVED means the container was confirmed absent rather than just terminated.
Queued or replacement deployments show up in the same deployments list query with their status (QUEUED, DEPLOYING, SUCCESS and so on). The mutations and statuses are documented in Manage Deployments with the Public API.
Status changed to Awaiting User Response Railway • 9 days ago
Railway
`deploymentStop` stops the running container but writes no status change: the deployment keeps reporting `SUCCESS` and its instances keep reporting as running. The mutation's response is not a completion signal, and no deployment or replica status proves that the stopped processes have finished. It does not cause a redeploy on its own. It is still not a guarantee that nothing runs again under that service. Platform-initiated host migrations and maintenance redeploys can recreate the workload on another host, and so can a new deployment triggered by you or your CI. We publish no signal or grace-interval contract specific to `deploymentStop`. If you need termination evidence, use `deploymentRemove`. It deletes routes, sends SIGTERM, escalates to SIGKILL once the draining period ends, then removes the container. The draining period is set per service through `RAILWAY_DEPLOYMENT_DRAINING_SECONDS`, service settings or `railway.json`, and defaults to 0. Removing the container ends every process inside it. The deployment moves to `REMOVING` and then `REMOVED`, and its instances follow, all readable through the public `deployment` / `deployments` queries. `REMOVED` is written only after teardown completes for every replica, so it is ordered evidence. One caveat: if the host is already gone, `REMOVED` means the container was confirmed absent rather than just terminated. Queued or replacement deployments show up in the same `deployments` list query with their status (`QUEUED`, `DEPLOYING`, `SUCCESS` and so on). The mutations and statuses are documented in [Manage Deployments with the Public API](https://docs.railway.com/integrations/api/manage-deployments).
9 days ago
Please have a Railway engineer confirm the four questions above as an official lifecycle contract. The automated answer adds deploymentStop/deploymentRemove guarantees that are not stated in the linked documentation. We need human confirmation of signal/grace, restart suppression, and complete replica-termination evidence.
Status changed to Awaiting Railway Response Railway • 9 days ago
8 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 8 days ago
8 days ago
deploymentStopdoesn't restart the container even if it's onALWAYS. It just kills the process.SIGTERMis supplied wh en a new deployment,deploymentStop, ordeploymentRemoveis triggered. The drain/grace interval applies when a deployment is removed or a new deployment is being built.SIGKILLwill be sent when a process hasn't terminated within the drain interval.- You can verify the deployment's status through the
deploymentquery. - You can't access status by replica but you can get the service's status through the
serviceInstancequery or deployment's status through thedeploymentquery.