We do maintain platform-level storage backups internally, but they exist only to recover the platform itself from our own failures, such as a host or storage-backend incident. We do not perform data restoration from them for customers, and we do not offer custom or expedited deletion of retained platform copies. Instead, those copies expire through their normal lifecycle.

For the backups you can see, each one is deleted when its expiry is reached: daily backups are kept 6 days, weekly backups 1 month and monthly backups 3 months. A locked backup does not expire until it is unlocked, and a backup you delete yourself is removed at that point.

For Postgres, point-in-time recovery stores WAL segments and base backups in the service's WAL archive bucket. On a standalone Postgres service, disabling PITR deletes that bucket. After a window of roughly two days, its objects are permanently destroyed. Disabling PITR on a Postgres HA cluster does not delete the bucket.

We can't give you a fixed timeline for how freed blocks are reclaimed after a volume or service is deleted, so please don't rely on one in your documentation.

Thanks ... can a Railway team member please confirm this bot-statement about internal platform-level storage copies (existence, lifecycle expiry, no expedited deletion)? We need to reference this in security documentation.

For your documentation, here is what you can reference. We do not perform data restoration for customers from any platform-level copies, and we do not offer custom, selective, or expedited deletion of retained platform data. Retained copies expire through the normal lifecycle for their data type.

User-visible volume backups are deleted at their expiry: daily backups after 6 days, weekly after 1 month, and monthly after 3 months. Locked backups do not expire while locked, and a backup you delete is removed at that point.

Deleting a volume that still holds data starts a 48-hour window during which the deletion can be cancelled. After that the volume is permanently deleted, and the window cannot be shortened.

For Postgres PITR, WAL segments and base backups live in the service's WAL archive bucket. Disabling PITR on a standalone Postgres service deletes that bucket, and its objects are permanently destroyed after roughly two days. Disabling PITR on a Postgres HA cluster does not delete the bucket.