Do you have a specific deployment ID we can look into?

Sure,

this was the correct deployment ID: 280abc25-d12c-47c5-84f2-82966f628ca7,

this is the old commit that was randomly deployed: ed8b3774-41dd-4444-a537-2bf3c4d6c0d0,

and then I redeployed the correct one again: e0663d5f-c4f3-479a-a63a-7292767537e9

Thanks for those IDs. We're checking what triggered deployment ed8b3774 — specifically whether it was a GitHub webhook, a scheduled redeploy, or an internal event. Will follow up with what we find.

Thank you!

Since this directly affected my production database (deleted data since they were inside nonexistent fields), what is the best way to handle such cases? On my hobby plan, there is no backup, so I had to manually recreate some of the data. This would be impossible if the scale of the project was bigger.

This is currently a single report, so we're unable to investigate the root cause further at this time. We are tracking this issue organically and will look into it when additional reports surface.

Regarding your question about handling such cases, application-level concerns like database schema compatibility and data protection strategies fall outside the scope of what we can assist with here. We're unable to provide application architecture suggestions.

There's no automated backups but you can always backup your database yourself. 🙂

I'm personally backing up my DB outside of Railsway every day.