2 months ago
Could a Railway engineer clarify the platform contract for manual Restart (not Redeploy)? This is a general documentation question, not a request to change any service.
The deployments reference describes Restart as restarting the process inside the container:
https://docs.railway.com/deployments/reference#restart
The recovery guide describes the existing container:
https://docs.railway.com/guides/roll-back-bad-deploy#rollback-vs-redeploy-vs-restart
But the Agent SDK guide says ephemeral files disappear on deploy or restart:
https://docs.railway.com/guides/claude-agent-sdk-app
For a single-replica Docker-image service with an existing attached volume:
- Does manual Restart guarantee preservation of runtime-created files and runtime changes to the entrypoint in the writable root filesystem, or can it recreate/reset that filesystem?
- Does the old process tree completely exit before the entrypoint runs again, with the volume already mounted?
- What SIGTERM/grace/SIGKILL behavior applies specifically to manual Restart? Is RAILWAY_DEPLOYMENT_DRAINING_SECONDS relevant to that action?
- If preservation is not guaranteed, is there a supported way to stop application writers gracefully and copy an ephemeral directory to the existing volume before the old filesystem is discarded?
A successful individual restart test or reuse of the same image would not establish a preservation guarantee. Please distinguish guaranteed behavior from best effort, including failure/host-replacement paths. No project identifiers, logs, credentials or customer data are included. Thank you.
1 Replies
2 months ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • about 2 months ago
2 months ago
Taking your four questions in order, and flagging which answers are guaranteed
versus which need a Railway employee to confirm.
- Does Restart preserve the writable layer?
Treat it as no. The deployment-actions doc describes Restart as "restores the
exact image containing the code & configuration of the original build" — that's
image-restore language, not resume-the-running-container language, and it's
consistent with a fresh container from the image. The docs don't state the
ephemeral-filesystem behaviour for this specific action outright, so that's
inference from wording rather than a documented guarantee.
You can settle it for your own configuration in two minutes rather than trusting
my reading: railway ssh in, touch a marker file outside your volume path, hit
Restart in the dashboard, ssh back in and look. That's definitive for your setup
and worth doing before you design around either answer.
- Process lifecycle and mount ordering.
Not documented anywhere I can find, and I won't guess at it — whether the old
process is fully reaped before the new entrypoint runs, and the exact point
volumes attach relative to entrypoint start, are internals only Railway can
state authoritatively.
- SIGTERM / grace period / SIGKILL, and RAILWAY_DEPLOYMENT_DRAINING_SECONDS.
The variable is real and does govern draining. The precise signal sequence and
the default grace window before SIGKILL are not something I can source from
public docs, and those exact numbers are the whole point of your question — so
that's the specific thing worth pressing Railway on rather than accepting a
community guess.
- Migrating ephemeral data to a volume on shutdown.
This is the one I'd push back on regardless of what the answers to 1–3 turn out
to be. Any shutdown-time migration is best-effort by construction: it depends on
receiving SIGTERM, on finishing before SIGKILL, and on the container exiting
cleanly rather than the host disappearing. A node failure, an OOM kill, or a
hardware fault gives you no shutdown hook at all, and those are exactly the
cases where you most want the data.
If the data matters, write it to the volume as it's produced rather than
relocating it at exit — write-through, or write directly to the volume path and
skip the ephemeral staging entirely. Keep a SIGTERM handler if you want to flush
buffers cleanly, but treat it as an optimisation, never as the durability
mechanism. That's the distinction you asked for between guaranteed and
best-effort: writes to the volume are durable, anything that has to happen
during shutdown is not.
