22 days ago
Hello Railway team,
I am reposting in English as requested in the previous thread:
https://station.railway.com/questions/mantenimiento-planificado-drenado-de-pe-3c990b82
We run a single-replica Flask/Gunicorn service on the Hobby plan.
SQLite is on an attached persistent volume, but some required files
are currently outside that volume.
We already have a consistent SQLite hot backup and a verified copy
of the available files. However, these are not a confirmed combined
point-in-time snapshot.
We accept a short planned outage. We do not need zero downtime.
Please provide one supported, step-by-step procedure to:
- Block new incoming requests and allow requests already running
to finish, explaining what public/private traffic is covered.
- Confirm that those requests have finished, including what happens
if the shutdown timeout expires.
- Capture the database and required files before the old container
is removed. Can we keep that container accessible after draining?
If not, what supported alternative should we use?
- Replace the deployment safely, including the relevant settings
and recovery limitations for our Hobby service with a volume.
We have tested an application-level maintenance mechanism separately,
but it is not installed in production yet. We need to resolve this
first transition.
We understand that coordinating internal application writers is our
responsibility. We are asking about Railway's platform behavior,
not requesting changes to our service or a plan upgrade.
Thank you.
1 Replies
22 days ago
Services with an attached volume have a small amount of downtime on every redeploy because we prevent multiple deployments from being active and mounted to the same volume simultaneously (docs). There is no way to keep the old container accessible after the new deployment starts.
The graceful shutdown window is controlled by RAILWAY_DEPLOYMENT_DRAINING_SECONDS (default 0). Set it to a value that gives your application time to finish in-flight work before the process is stopped (docs). Both public and private-network callers are affected by the switchover.
Volume data persists across redeploys, so your SQLite database on the volume is safe. Files outside the volume are on ephemeral storage and are lost when the container is removed. Move those required files onto your volume mount before redeploying.
Status changed to Awaiting User Response Railway • 22 days ago
15 days ago
This thread has been marked as solved automatically due to a lack of recent activity. Please re-open this thread or create a new one if you require further assistance. Thank you!
Status changed to Solved Railway • 15 days ago