The volume is attached and reporting usage, but our databases are unmanaged, so automatic snapshots, WAL recovery, and PITR are not available to restore your data unless you had previously enabled them on the service. We do not recover data lost to user-initiated actions, including major version upgrades. Going forward, enable native volume backups and point-in-time recovery on your Postgres services from the service's Backups tab so you can self-restore if this happens again.

Thanks for clarifying that unmanaged Postgres has no automatic snapshots / WAL / PITR unless previously enabled, and that major-version upgrades are treated as user-initiated.

We need to correct the root-cause framing:

This was NOT a user-initiated delete of the original production sandbox

The original project was removed/destroyed when our Railway trial ended and payment method / account balance was not funded in time. Railway automatically deleted or deprovisioned the project because the trial expired — we did not intentionally delete the live sandbox that ran our casino operation (player accounts, wallets, ledger, custom domains).

That automatic trial/billing teardown effectively wiped our operation. Afterward we tried to rebuild in a new project (positive-reverence) and attempted recovery from a remaining volume; a Postgres major upgrade then left that volume reporting ~843MB in the UI while the mounted cluster is empty (~47MB, 0 app tables). We understand you may not undo major upgrades via PITR — but restoring data lost to trial expiry / automatic account teardown is a different request.

Ask — restore from Railway trial expiry / soft-delete retention

1. Please search this workspace for projects/volumes soft-deleted or deprovisioned due to trial expiry / unpaid account around early/mid August 2026 (especially ~2026-08-15), including any original project named desirable-emotion that hosted:

• Services: casinha-sandbox, casinha-front-sandbox, casinha-adm-sandbox, Postgres
• Domains: api.ricaobet.com, www.ricaobet.com, admin.ricaobet.com / ricaobet.com
• Workspace ID: 366b4ee7-0450-45a3-b58d-382ba2701da8
• Account email: eduardojonas244@gmail.com

1. Soft-deleted project still visible:

• Project name: desirable-emotion
• Project ID: 802ce642-40bb-4e20-a4d8-4f01b9f772ab
• deletedAt: 2026-08-17T14:26:39.156Z
• Environment ID: f95a4d39-d1b0-47c3-9404-574325251445

Please restore this if it still contains the original services/volumes. If it was only an empty recreate, please still locate the original trial-expired project/volumes.

1. Please resend any “Restore Volume” / “Restore Project” emails to eduardojonas244@gmail.com and confirm whether the 48h (or any extended) retention window still applies for trial-expiry deletions.

2. Volume still attached in the rebuild project (possible remnant of the old DB):

• Volume ID: 3ff7a25a-53a8-41e2-9f37-ce21b7b3c766 (postgres-volume)
• UI used size ~843MB vs mounted empty PG18 ~47MB

If Railway retains a pre-teardown or pre-upgrade block image of this volume, please expose it as a restorable volume.

This held live player balances and accounts. The outage was caused by trial expiry automation, not an intentional wipe by us. We are asking for platform recovery under soft-delete / trial-deletion retention.

If recovery is impossible, please say so explicitly and confirm the exact retention policy for trial-expired projects/volumes so we can close this path.

Thank you.

To address each point directly: this workspace was created and upgraded to Pro on 2026-08-15, with no prior trial period on this account, so there was no trial-expiry teardown to recover from. The project desirable-emotion was deleted from the dashboard on 2026-08-17 and contained no services or volumes at that time; its 48-hour restore window has since closed. Dashboard-deleted projects carry a 48-hour window to undo the deletion, after which the resources are permanently removed. The volume postgres-volume is still attached and reporting usage, but the in-place data loss from the PostgreSQL 18 major upgrade is not something we can restore. We do not recover data lost to user-initiated actions, and no volume backups or point-in-time recovery had been enabled on this service beforehand. Going forward, enable native volume backups and PITR on your Postgres services from the service's Backups tab so you can self-restore if this happens again.

Following up with a definitive answer, since you asked for one. We went through the backend records directly. Railway's automated major-version upgrade never ran on this service or anywhere in this workspace, and the .railway-major-upgrade.lock file is a marker the Postgres image writes on every boot, not evidence of an upgrade. The PG18 cluster on postgres-volume was initialized fresh on Aug 15 when the Postgres-Recovery service was created and the volume attached, and all of the activity in that window came from your own account's sessions.

On recovery: no snapshot of this volume exists on our side. Backups and point-in-time recovery were never enabled on it, and we don't keep block-level copies otherwise. The 843MB in the dashboard versus 47MB inside the container is storage accounting for data that's already been deleted at the file level, not a hidden recoverable copy. As my colleague said, this workspace was created on Aug 15 with no prior trial, desirable-emotion held no services or volumes when it was deleted, and its 48-hour window has closed. So, explicitly: there's nothing on our side to restore, and you can stop waiting on this path. Any recovery would have to come from copies outside Railway.