I'd recommend mounting a volume to your service. Ephemeral volumes do not persist across deployments.

And no, it's not possible to recover data that was stored in ephemeral environments after a redeployment.

Short answer: it depends entirely on where the data was stored, and in the most common version of this story, the data is unfortunately not recoverable. Here's how to work through it.

Why this happened

Rolling back the code didn't help because the data was never in your code. Git only versions your source. The data lived (or should have lived) in one of three places on Railway:

1. The container's filesystem (e.g., a SQLite file, a JSON file, or uploads saved next to your app code). Railway containers are ephemeral: every deploy builds a fresh image and discards the old container's filesystem. If your ~70 entries were in a SQLite/file store with no Volume attached, they were wiped the moment you redeployed and every previous deploy silently wiped them too if you had any.
2. A Railway Volume mounted into the service.
3. A separate database service (Railway Postgres/MySQL/Mongo). These persist across deploys of your app data loss here usually means something else happened (see below).

Recovery options, in order of hope

If you had a Volume attached: open the service in Railway → the Volume → Backups tab. Railway takes automatic snapshots of volumes (daily on paid plans, and you can trigger manual ones). If a snapshot exists from before the redeploy, you can restore it this is your best-case scenario.

If the data was in a Railway database service (Postgres etc.): the data shouldn't vanish on an app redeploy, so check whether:

• Your DATABASE_URL changed — you might be connected to a new, empty database service while the old one still exists in the project (or in another environment). Check the project canvas and Variables for orphaned DB services; the data may just be "elsewhere," not gone.
• A migration or ORM setting dropped your tables. Common culprits: TypeORM synchronize: true, prisma migrate reset / prisma db push with data loss accepted, Sequelize sync({ force: true }). If the new feature added schema changes, this is very plausible.
• The database service itself has volume backups (same Backups tab) Railway Postgres sits on a volume, so a snapshot may exist.

If it was SQLite/files on the container with no Volume: there is no built-in way to get it back. The old container image's writable layer is discarded on redeploy and Railway doesn't retain it. It's still worth opening a ticket with Railway support (station.railway.com or help@railway.com) right away they occasionally can help if a detached volume still exists in the project but set your expectations low.

What to do next

• Right now: don't redeploy again or delete anything in the project until you've checked for orphaned database services and volume backups — restore points are the first thing further changes destroy.
• Going forward: move persistent data into a Railway Postgres service (or attach a Volume if you must keep SQLite), turn off any auto-sync/auto-drop schema options in production, and set up scheduled backups (Railway's volume backups, or a nightly pg_dump cron to external storage).

If you tell me what the app actually used for storage (SQLite? Postgres? flat files?) — or point me at the repo — I can look at the config and tell you definitively which scenario you're in and whether a recovery path exists.