The preservation tools we offer for a service work on volume data, not on a running process. Volume backups capture what is stored on the volume, such as your SQLite database and JSON files. They do not include the Python heap, threads, open file descriptors or background tasks. A backup can only be restored into the same project and environment. Restoring it creates a new volume and redeploys the service, so it starts a new process and does not resume the old one.

Process state also cannot be guaranteed to survive. If the server your service runs on fails, we move the workload to a healthy server, and the service restarts there. In-memory state and in-flight work are lost when that happens.

The closest control you have is the restart policy. Setting it to Never stops us from restarting the service automatically after it exits, but it does not prevent a restart when we move the workload off a failed server.

For a migration that needs to keep runtime state, the app has to persist that state to the volume itself before the cutover.

Thank you for the explanation.

I understand that Railway volume backups do not preserve the running Python process or its in-memory state.

Before making a migration decision, could a Railway engineer please confirm whether there is any officially supported method to preserve or export the original running process state for a standard Railway service?

If no such method exists, please confirm that explicitly.

We are not requesting any changes to our production service. This is an information-only inquiry.

Thank you!

None of the preservation features we offer for a standard service keep a running process's state. Volume backups capture only what is on the volume, and restoring one creates a new volume and redeploys the service, which starts a fresh process. Even our sandbox checkpoint and fork features, which snapshot a disk, boot fresh: files are kept but running processes are not.

So we have no feature that exports or restores a service's Python heap, threads or open file descriptors, and no checkpoint that resumes the original process somewhere else. For a migration, any runtime state you need has to be written to the volume or another store by the application before cutover.

Thank you for clarifying the process-preservation limitations.

I have one final technical capability question about our existing Python service.

Without restarting the service, changing its security configuration, or attaching any diagnostic tool now, is Railway able to confirm:

1. The Python interpreter version of the currently running deployment.
2. Whether Railway's current container security policy permits a provider-approved, cooperative CPython attachment to an existing same-UID process.

We understand that attachment does not guarantee an application-consistent snapshot.

This is an information-only inquiry. Please do not attach to, signal, inspect memory, modify or restart the running process.

Thank you.

We can't confirm the interpreter version from here, because no deployments show up on the account this thread was opened from. We have not looked at, attached to, or changed anything in your service.

On attachment, we don't offer a supported or provider-approved way to attach to a running process in a service. We also don't let customers view or configure container security settings, such as capability sets, seccomp or AppArmor profiles, on any plan. So we can't give you a security-policy guarantee that a same-UID CPython attach would work. Your migration plan shouldn't rely on that kind of attach to capture state.