One History for the backend
Schema, auth, storage, functions, webhooks, environment variables, API keys and integrations: each change is one entry, with who made it and what it touched, whether your agent, Backenly or you made it.
Undo a change, keep your data
Every change to your backend is one entry in History. Restore the state before one change, or roll the backend back to a point or a published version, and the rows your app wrote since are never rewound.
Undoing a change, over MCP
You: Checkout broke after the last
change. Undo it.
Agent: deploy changes
#41 renamed orders.total to
amount. Verified.
Agent: deploy revert_change #41
Parked for your approval:
amount goes back to total.
No data is set aside.
You: (approves it in the dashboard)
Agent: check_approval: executed.
Checkout reads total again, and
every order since is still there.What you get
Undo one change
Restore the state before a single change and leave everything else as it is. Backenly measures the restore first and says why when it cannot run one, for example when a later change touched the same table.
Back to a point or a version
Restore the backend to a moment in History or to a published version. The changes since are undone newest first, each one checked before it runs and verified after.
Your data stays
Rows your app wrote are never rewound. A restore that would set any data aside says exactly what and waits for a person, and a secret or a revoked key never comes back.
Questions
Open History in your project and restore the state before that change. Or ask your agent: it can request a restore of one change, or of the whole backend to a published version, and a person approves it in the dashboard. An agent can ask for a restore; it can never approve one.
No. A restore never rewinds rows your app wrote. If undoing a change would set data aside, such as removing a column that has been filled in since, Backenly shows exactly what before anything runs and waits for a person to approve it. A restore is itself recorded in History, so you can reapply what you undid.
Yes, on every plan. The plan sets only how long a change stays restorable: 7 days on Free, 30 on Pro and 90 on Enterprise, or 365 when you self-host.
A backup puts the whole database back to a moment, and every row written since is lost. History undoes one change, or the changes since a point, and leaves the data your app wrote where it is. Backenly Cloud keeps daily backups as well, for disasters.
A restore that crosses a later change to the same table is refused rather than merged, and a change older than your plan's window can no longer be restored. A secret or a revoked key never comes back. Row data your app writes is not versioned; only data a change itself removed or rewrote is kept.