Automatic backups

Backups in Runwork protect your workspace data with automatic snapshots. Unlike app versioning which tracks code changes, backups protect your actual data: the entities, records, and files that your apps create and manage.

Every time a version goes live, Runwork takes a snapshot of your data alongside it. There is nothing to configure and no schedule to maintain, because the trigger is the deploy itself. If you have deployed, you have a snapshot.

Restoring puts your data back as it stood at a previous deploy. That returns anything removed since, and it also removes anything added since, because a restore replaces the dataset rather than merging into it. So it is the right tool for a bad migration or a bulk update gone wrong, and the wrong one for a single record deleted this afternoon.

Code and data restore separately. A deploy that broke the app can be rolled back on its own, leaving everything your team has entered since exactly where it is. Or the data can go back under code you want to keep. Most teams need one or the other, rarely both, and being forced to take both is what makes rollbacks frightening elsewhere.

Your data is yours to take out at any time, not just to restore. A full workspace export runs as a job on our side and returns every entity as JSON or CSV, from the browser, the desktop app or the CLI, and the desktop path resumes where it left off if the connection drops. Nothing you put in here is trapped, which is the part that matters if you are deciding whether to put anything in at all.