Mantenimiento de servidores

Actualizaciones de sistema operativo

La página de cada servidor tiene una tarjeta Operating system. Railyard reporta las actualizaciones pendientes dentro de la primera media hora de conectar el servidor y luego a diario: cuántas en total, cuántas son actualizaciones de seguridad, y si se necesita un reinicio.

• Install all updates o Install security updates and restart. Actualizar puede reiniciar Docker, así que las apps pueden parpadear por unos segundos; un reinicio tumba las apps del servidor por un minuto aproximadamente.
• Nightly security updates se aplican sin supervisión; un reinicio nunca se hace automáticamente.
• El badge se limpia una vez que el servidor se reinició.

Upgrades de versión mayor de Postgres

Un Postgres administrado puede pasar de 16 a 17 o 18 desde su tarjeta. Railyard primero verifica la compatibilidad, toma una copia de seguridad, actualiza en el mismo lugar y verifica el número de tablas. La versión anterior se guarda por siete días para que puedas hacer rollback. Los servidores de base de datos nuevos usan Postgres 17 por defecto.

Recuperación a un punto en el tiempo

Maintenance → Point-in-time recovery → Turn on archiva cada segmento WAL y una copia de seguridad base del Postgres del servidor en el almacén de copias de seguridad de tu equipo, así cualquier base de datos ahí se puede reconstruir a cualquier segundo de los últimos 7 días.

Para restaurar, abre la consola de la base de datos (App → Resources → Database card → Console) y usa la pestaña Restore to a time: elige un segundo dentro de la ventana archivada, y luego Into a new copy (<db>_at_YYYYMMDDHHMM, inspecciónala y copia de vuelta lo que necesites) o Replace the live database (todo lo posterior a ese momento se pierde). Restaurar necesita el mismo almacén de copias de seguridad que usan las copias regulares.

Snapshots

Antes de un resize o un upgrade del sistema operativo, toma un snapshot del proveedor desde la página del servidor y restáuralo si algo sale mal. Los snapshots los guarda tu proveedor de nube y él te los cobra.

Aislamiento reforzado (beta)

En Settings → General de una app, dos ajustes opcionales, desactivados por defecto, cierran la frontera del contenedor entre apps que comparten un servidor:

• Hardened isolation: el contenedor de la app corre con su propio uid no root, con capabilities eliminadas y su propia red de Docker, así que no puede alcanzar ni ser alcanzado por otra app del servidor. Pruébalo primero — puede romper una imagen que necesita root.
• Read-only filesystem: monta el filesystem raíz del contenedor como solo lectura con un /tmp donde sí se puede escribir. Actívalo solo después de verificar que la app no escribe en ningún otro lugar.

Ambos surten efecto en el siguiente despliegue. Cada servidor todavía comparte un solo kernel; el aislamiento con runtime en sandbox (gVisor) está en el roadmap pero aún no está construido.

Puntaje de seguridad

Settings → Security le da al equipo un puntaje de 0 a 100 contra una checklist, con un enlace de corrección por ítem; consulta Teams, SSO and access para la lista completa. Cada conexión a tu servidor se autentica sobre TLS con credenciales únicas para ese servidor.