Backups and rollback
A bad release is one click from being undone.
Every publish takes a database snapshot first and applies only additive schema changes. Every hand-made production edit is backed up too. Restore a snapshot or serve an earlier deploy again in one click, from the builder or by asking your agent.
- Before a production editToday 10:124.1 MB
- Before publishYesterday 18:304.0 MB
- Taken by handOct 9, 09:023.8 MB
- Before publishOct 8, 16:453.8 MB
Last 30 kept · deploy history: release 14 live, roll back to 13
- Snapshot first
- Before every publish and prod edit
- 30 kept
- With when and why each was taken
- One-click restore
- And the restore can be undone
- Deploy rollback
- Serve an earlier release again
How backups and rollback work
Publishing verifies the release, snapshots production, applies the additive schema changes and builds the app. Destructive changes wait for your go-ahead.
Backend, Backups lists the last 30 snapshots with why each was taken: before publish, before a production edit, or taken by hand.
Restore a snapshot to undo data, or roll back to an earlier deploy to undo files. A fresh snapshot is taken before a restore, so it can be undone too.
$ appbricx snapshots
prod-20261012T101217Z before a production edit
prod-20261011T183005Z before publish (release 14)
$ appbricx snapshots restore prod-20261012T101217Z --env prod
✓ restored (undo snapshot: prod-20261012T101228Z-prerollback)
$ appbricx deploys
14 live 13 12 11
$ appbricx deploys rollback 13
✓ serving release 13
Recovery built into every release
Automatic snapshots
Before every publish, before any hand-made production change from the builder or an agent, and whenever you take one by hand.
Additive publishes
New tables, columns and indexes go to production with rows kept; drops wait for an explicit destructive publish.
Restore in one click
Pick the snapshot from before the change and restore. Agents use the snapshots tool; the CLI has snapshots restore.
Deploy history
Every deploy is listed, and Roll back to this deploy serves that release again.
Audited production edits
Every write records who made it, which tool and which environment.
Nightly demo reset
Public demos with shared logins can reset to their seed data every night, with dates moved forward.
Ten demos that put themselves back every night
Every showcase app, Tablefor included, is published with the nightly demo reset: visitor changes and sign-ups are cleared, demo passwords restored, and times moved forward so tonight's bookings are still tonight's.
Works with
Backups and rollback: common questions
When are database backups taken?
Before every publish, before any hand-made change to production data from the builder or an agent, and whenever you take one by hand. The last 30 are kept.
How do I roll back a bad release?
Roll back to an earlier deploy from Backend, Backups, Deploy history to serve that release again, and restore a snapshot if the data needs undoing too.
Can a restore be undone?
Yes. A fresh snapshot is taken before every restore, so you can restore back to it.
Can my agent roll back?
Yes, with the snapshots and deploys MCP tools, if you granted it the deploy scope when you authorized it.