5 hours ago
I need clarification of Railway capabilities on an existing Hobby plan before a controlled worker replacement. This is an information request only; please do not stop, restart, redeploy or change any service.
The worker has a Python supervisor as PID 1 in its container PID namespace. It launches a long-running application and a periodic backup child. The legacy supervisor has no cooperative quiescence endpoint or lifetime lock. We must prevent any new backup from starting while allowing any already-running backup to finish. An idle process sample followed by stopping the deployment is not an atomic barrier: its SIGTERM handler sets a flag, but a previously-entered loop iteration could still launch a child. Same-namespace SIGSTOP cannot provide the required acknowledged pause for namespace PID 1.
Does Railway expose a supported host-side or ancestor-namespace supervisor-only pause/acknowledgment, or another documented quiescence mechanism, that leaves an existing child running? If not, please confirm that limitation. We are not requesting privileged access, credentials, a plan upgrade or a workaround that could interrupt a backup.
Separately, after a completed deployment is explicitly Removed, is its desired state reliably stopped without automatic restart? How should a caller resolve an uncertain Remove response through read-only deployment state?
No project identifiers, logs, private code or credentials are included. We only need the supported platform behavior and documentation for the current plan.
2 Replies
5 hours ago
We don't offer a host-side or ancestor-namespace pause, a per-process signal, or a quiescence hook for a single process inside a container. When a deployment is stopped or replaced, the container receives SIGTERM, then SIGKILL after the grace period set by RAILWAY_DEPLOYMENT_DRAINING_SECONDS (0 seconds by default), and we send no other signals. A barrier that blocks new backups while letting a running one finish has to come from the supervisor itself.
Remove stops the running deployment and marks it REMOVED, moving it into history. REMOVED is a terminal state: the deployment's restart policy no longer applies to it, and bringing that code back means starting a new deployment, for example with Redeploy or Rollback. The Remove call returns before shutdown finishes. To settle an uncertain response, poll deployment(id) and treat REMOVING as still in progress and REMOVED as complete. Also check that no other deployment for the service has become active, since only a new deployment can run the workload again.
Status changed to Awaiting User Response Railway • about 5 hours ago
5 hours ago
Thank you for clarifying the platform behavior. Our application requirement has changed: the obsolete periodic worker is being retired rather than carried forward, while separate existing recovery jobs remain unchanged. We will use an explicit deployment Remove and verify terminal REMOVED state and the absence of another active old deployment. We are not requesting any platform action, privileged access, plan change or paid feature. No further assistance is needed on the pause question.
Status changed to Awaiting Railway Response Railway • about 5 hours ago
Status changed to Solved Railway • about 5 hours ago