After a manual Remove, REMOVED is written only once teardown has finished for every replica of that deployment, so it is not just a traffic change. Routes are deleted, each instance gets SIGTERM, SIGKILL follows once the draining period ends, and then the container is destroyed. Destroying the container ends every process inside it, child processes included. You can read the deployment and instance statuses (REMOVING, then REMOVED) from the dashboard or the public API. One caveat: if the host is already gone, REMOVED means the container was confirmed absent rather than just terminated.

Remove uses the same draining window. It is set per service through the draining seconds setting in service settings, railway.json, or the RAILWAY_DEPLOYMENT_DRAINING_SECONDS variable, and it defaults to 0. Please set it long enough for your shutdown handling to finish.

The restart policy only covers a running container that exits on its own. Once a deployment reaches REMOVED, nothing restarts it, whatever exit code it returned during teardown. Only two things can start the workload again: a new deployment that you or your CI trigger, or a platform-initiated redeploy for host maintenance or migration. So waiting for REMOVED on every instance before you deploy the replacement is the supported check.

Your application is responsible for in-flight writes. That means catching SIGTERM, committing or rolling back database transactions, flushing and syncing files, and exiting within the draining window. The platform stops the container on schedule and does not check whether your writes completed.

Thank you. I understand that the application must finish or roll back its database and file writes; Railway does not verify their completion. Could a Railway staff member please confirm the platform guarantees below, with direct documentation where available?

1. Does REMOVED after a manual Remove confirm that every replica and child process has actually exited, or that their containers are confirmed absent?
2. While the deployment is still REMOVING, can exit code 75 trigger an On Failure restart? After removal, can platform maintenance redeploy that removed workload, or does that only apply to active deployments?
3. Where can we check the effective SIGTERM-to-SIGKILL grace period and start command for an already-running deployment, including precedence between service settings, config-as-code and variables?
4. What is the supported procedure to confirm that the old deployment cannot run again before starting its replacement?

Please distinguish platform guarantees from application responsibilities. This is a request for clarification, not for any service or configuration changes.

REMOVED is written only after teardown finishes for every replica of that deployment. Removal destroys the container itself, so every process inside it ends, child processes included. If the underlying host is already gone, REMOVED means the container was confirmed absent rather than just terminated, with the same end state. Statuses are readable in the dashboard or the public API.

Once a deployment is REMOVED, nothing restarts or recreates it. The workload can only run again through a new deployment, either one you or your CI trigger or a platform-initiated redeploy for host maintenance or migration. Restart policy covers a running container that exits on its own. We can't give a documented guarantee about how an exit code during REMOVING interacts with On Failure, so treat REMOVED, not REMOVING, as your checkpoint.

The deployment details page shows every setting a deployment went out with, including start command and draining seconds, and marks values that came from a config file. Config in code overrides dashboard settings, and environment-specific config overrides base config. Draining seconds can also be set with RAILWAY_DEPLOYMENT_DRAINING_SECONDS (teardown docs) and defaults to 0.

The supported check is waiting until the deployment and all its instances report REMOVED before deploying the replacement. Your application owns handling SIGTERM, finishing or rolling back transactions, syncing files, and exiting within the draining window. Because of platform-initiated redeploys, no service is guaranteed restart-free.