7 hours ago
Hello Railway team,
I need platform-level guidance for backing up the volume of a short-lived WATCHDOG cron service on the Hobby plan. It runs every 15 minutes and exits normally between runs. Operational monitoring and alerts must continue unchanged.
Environment: Railway CLI 5.71.0 on Windows; SQLite with WAL on an attached volume. SSH authentication works for other running services. Attempts during natural WATCHDOG runs did not obtain a backup. Between runs SSH returned: “Connection to ssh.railway.com closed by remote host.”
The read-only command railway volume files --volume list / --json returned:
Failed to list / after reconnect
Caused by:
0: Failed to initialize SFTP session
1: Timeout
Can a supported procedure satisfy all five requirements?
- Export the volume while its cron service is inactive, without starting, waking, restarting, modifying, redeploying, or detaching/remounting the service or volume.
- Obtain a consistent SQLite copy including committed WAL data, rather than independently copying changing database/WAL files.
- Transfer and restore the copy in an isolated local environment without running the application, cron jobs, or notification automations, and without replacing the production volume.
- Use the current Hobby plan without upgrades or additional paid resources. Please identify any unavoidable incremental charges before suggesting an operation.
- Ensure the procedure does not delay or otherwise interfere with the next scheduled cron execution, including concurrent-write safety.
The 29 May 2026 CLI volume announcement describes direct SFTP access without a running service container; the SSH documentation describes a running container. Which applies to an idle cron service? Is an independently exportable atomic snapshot available?
Clarification only: please do not perform production changes, restarts, restores, upgrades, or billable actions. If these requirements cannot all be met, please explain the exact limitation and least invasive supported alternative. No credentials or database contents are included.
Thank you.
2 Replies
7 hours ago
These five requirements can't all be met together today. Here's what blocks it.
The CLI's railway volume files commands reach a volume through the service it's attached to, and they need that service to have an active deployment. They don't give direct access to a stored volume or backup. Between runs your WATCHDOG cron has no running container, so there's nothing to connect to. That fits the closed connection and SFTP timeout you saw. These commands also use SFTP over SSH, so they can't get around an SSH connection failure.
Volume backups take a point-in-time snapshot of the whole volume. Your SQLite database and its WAL file are captured together at the same moment. That snapshot is crash-consistent, not application-consistent, so recovering it depends on SQLite's own WAL recovery. Backups can't be exported on their own, though. There's no downloadable archive, and restores stay in the same project and environment. A restore also creates a new volume and stages a swap, and deploying that swap redeploys the service. So it isn't a read-only or isolated local export.
In short, there's no supported way to export the volume, or a consistent snapshot of it, while the cron service is idle without changing or running something in production.
Status changed to Awaiting User Response Railway • about 7 hours ago
Railway
These five requirements can't all be met together today. Here's what blocks it. The CLI's `railway volume files` commands reach a volume through the service it's attached to, and they need that service to have an active deployment. They don't give direct access to a stored volume or backup. Between runs your WATCHDOG cron has no running container, so there's nothing to connect to. That fits the closed connection and SFTP timeout you saw. These commands also use SFTP over SSH, so they can't get around an SSH connection failure. Volume backups take a point-in-time snapshot of the whole volume. Your SQLite database and its WAL file are captured together at the same moment. That snapshot is crash-consistent, not application-consistent, so recovering it depends on SQLite's own WAL recovery. Backups can't be exported on their own, though. There's no downloadable archive, and restores stay in the same project and environment. A restore also creates a new volume and stages a swap, and deploying that swap redeploys the service. So it isn't a read-only or isolated local export. In short, there's no supported way to export the volume, or a consistent snapshot of it, while the cron service is idle without changing or running something in production.
7 hours ago
Thank you for the explanation. I still need help: could a human Railway support engineer please confirm the platform limitations described by the Railway BOT before we decide how to proceed?
Please confirm:
- Whether there is no supported direct export of a volume attached to an idle cron service without starting/waking, restarting, modifying, or redeploying that service.
- Whether Railway offers any exportable, consistent SQLite snapshot including WAL, and whether native snapshots are only crash-consistent and non-exportable.
- Whether an isolated restore is possible without swapping the production volume or redeploying/running the production application.
- Whether any officially supported alternative satisfies these requirements on our current Hobby plan, with no upgrade, additional paid resources, production changes, or interference with the next scheduled cron run. If not, please confirm that explicitly.
This is a request for human clarification only, not authorization for any operational action or cost. Please keep this in the existing thread. We are not repeating SSH/SFTP attempts or deploying backup code while awaiting confirmation.
Thank you.
Status changed to Awaiting Railway Response Railway • about 7 hours ago
3 hours ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • about 3 hours ago