Mantenimiento planificado: drenado de peticiones y preservación de archivos antes de reemplazar un despliegue
ercona
HOBBYOP

21 days ago

Hola, equipo de Railway:

Tenemos un servicio Flask/Gunicorn de una réplica, con SQLite en un volumen y archivos persistidos también fuera del volumen, en el plan Hobby. Queremos preparar un cambio de despliegue seguro. Aceptamos una interrupción breve y planificada; no necesitamos cero downtime.

  1. ¿Qué procedimiento soporta Railway para impedir nuevas peticiones y permitir que terminen las ya iniciadas antes de un cambio?

  2. ¿Cómo podemos comprobar esa finalización y qué sucede cuando se agota el tiempo de cierre?

  3. ¿Puede mantenerse accesible el contenedor anterior para capturar SQLite y los archivos antes de retirarlo? Si no, ¿qué procedimiento recomienda Railway para preservar archivos fuera del volumen?

  4. ¿Qué pasos, limitaciones y recuperación corresponden a este tipo de servicio y a nuestro plan Hobby actual?

La consulta se limita al comportamiento y procedimientos soportados por la plataforma. No pedimos que Railway certifique nuestro código ni nuestras tareas internas. No solicitamos cambios en servicios ni contratación de planes. Gracias.

Closed

1 Replies

Railway
BOT

21 days ago

Apologies, we only correspond in English. Please open a new thread in English.


Status changed to Closed Railway • 21 days ago


Welcome!

Sign in to your Railway account to join the conversation.

Loading...