Removing a deployment with the public API's deploymentRemove mutation stops routing to it, sends SIGTERM, escalates to SIGKILL after the service's draining period (default 0 seconds, configurable with RAILWAY_DEPLOYMENT_DRAINING_SECONDS), then removes the container. Because the container itself is destroyed, every process inside it ends, child processes included, so nothing survives removal. The deployment moves to REMOVING and then REMOVED, and REMOVED is written only after teardown has completed for every replica; you can confirm it independently by querying the deployment's status through the API. If the underlying host is already gone, REMOVED means the container was confirmed absent rather than just terminated.

Use deploymentRemove rather than deploymentStop: stop halts the container but leaves the deployment reporting SUCCESS, so it gives you no completion signal. Both are covered in Manage Deployments. Note that no run is guaranteed restart-free, since we can redeploy a service to migrate it between hosts for maintenance, and exceeding the ephemeral storage limit also forces a redeploy.

Images pinned by digest (ghcr.io/org/image@sha256:...) are accepted as a service source. Private registry credentials require the Pro plan, and for GHCR you supply a GitHub personal access token (classic) with the read:packages scope in the service's Registry Credentials setting, per Private Registries.

Per-service outbound network restrictions are not supported on any plan. Every container has unrestricted outbound internet access, and leaving a service without a public domain restricts inbound traffic only.

Thank you. Could a Railway team member please confirm two points from the automated response?

1. Does REMOVED guarantee that teardown has completed for every replica of that exact deployment, including termination of all processes inside its containers? The linked API documentation lists REMOVED but does not appear to specify this completion guarantee. A documentation reference or explicit team confirmation would help.

2. Is there currently no supported per-service egress firewall or deny-all outbound policy on any plan?

We understand that disabling a public domain affects inbound access only. Our requirement is to restrict outbound network access from a file-scanning workload.

These answers will determine whether we use Railway for the scanner itself or retain Railway for coordination and place only the scanner in a separate execution environment.

No private project details are needed for this capability question. Thank you.

Yes on both points.

REMOVED is written only after teardown has completed for every replica of that deployment, not when it begins, so observing it is ordered evidence that the deployment ended. Removal destroys each container rather than signalling into it, so every process inside, including child processes regardless of parentage, ends with it. The one nuance is that if the underlying host is already gone, REMOVED means the container was confirmed absent rather than just terminated; the end state is the same. You can read the deployment and its instances' statuses through the public API, as covered in Manage Deployments.

There is no per-service or per-deployment egress firewall, outbound allowlist, or deny-all outbound policy on any plan. Every container has unrestricted outbound internet access, and this is the same on Hobby, Pro, and Enterprise.

Thank you. Please escalate this to a human support engineer. We need confirmation that REMOVED is published only after all replicas’ containers are destroyed or confirmed absent, including all contained processes. Please also confirm that no supported per-service outbound network restriction is available. We are choosing a hosting architecture and need a human-reviewed answer before relying on these guarantees.

Confirming both points.

REMOVED is written only after teardown has finished for every replica of that deployment, not when teardown starts. Removing a deployment destroys each container rather than signalling into it, so every process inside ends with it, child processes included, whatever their process group or parent. There is one case to know about: if the host underneath has already gone away, REMOVED is recorded because the container was confirmed absent, not because it was just terminated. The end state is the same. You can read the deployment's status and its instances' statuses through the public API, as described in Manage Deployments.

There is no supported per-service or per-deployment egress firewall, outbound allowlist, or deny-all outbound policy on any plan. Every container has unrestricted outbound internet access, and that is the same on Hobby, Pro, and Enterprise. If the scanner must run with outbound access restricted, that requirement can't be met on Railway today.

Hi, thanks for clarifying what you need. To set expectations: I'm a community member, not Railway staff, so I can't escalate this thread or give you an engineer-validated answer myself. The replies above, including the automated one, are the only answers on the thread so far, and I can't verify who wrote them.

From what I found, Hobby, Free and Trial plans only get community support, while Pro plans get direct help from Railway through Central Station, usually within 72 hours. If you need written confirmation from the Railway team before choosing your architecture, a private thread on a Pro plan is the most reliable way to get it. Since you would need Pro for private registry credentials anyway, that may be worth considering.

On your two questions, here is my own reading of the public information:

1. REMOVED guarantee: the docs describe the REMOVING → REMOVED lifecycle and the SIGTERM/SIGKILL sequence, but I couldn't find a sentence in the official documentation that explicitly states the guarantee you are asking for.
2. Outbound restrictions: I couldn't find any per-service egress firewall or allowlist in the docs. The outbound options I found are static outbound IPs (Pro) and optional IPv6, and neither blocks traffic.

Until you get a validated answer, I would suggest an independent end-to-end test: start a child process that sends a heartbeat to an external endpoint, call deploymentRemove, then check that the heartbeat stops once the status shows REMOVED. If your scanner strictly requires a closed network, isolating it outside Railway seems the safer choice given what is documented today.