Version history and rollback

Vorx saves every change as a checkpoint. That safety net is what lets you experiment freely — nothing you do is permanent until you decide it is.

Every edit is saved

Each change Vorx applies becomes a point in your project's history, in order, with a short description of what changed. You don't have to save anything yourself; it happens automatically. Chat edits, visual edits and your own code changes are all captured the same way.

Roll back in a click

Open the history and restore any earlier checkpoint. Your app returns to exactly how it was at that point — code, layout and all. If a rollback wasn't what you wanted either, you can move forward again.

You can also just ask in chat — "undo that" — and Vorx reverts the last change.

Rollback is free

Rolling back doesn't call a model, so it doesn't cost credits. This is worth knowing, because it means backing out of a bad edit is always cheaper than trying to describe your way forward out of it.

Experiment without worry

Because you can always return to a known-good state, it's safe to try a bold change. Ask for the ambitious version; if it doesn't land, roll back and try a different tack.

A clean starting point

If a project has wandered somewhere you don't like after a run of edits, rolling back to an earlier checkpoint is usually faster than describing your way out — reset to solid ground and take a different path from there.

What rollback doesn't undo

Checkpoints cover your app's code and structure. They aren't a database backup: rows your app created, and changes you made by hand in Settings → Cloud → Database, aren't rewound by a rollback. Nor does rolling back your working copy change what your users see — that stays as it was until you publish again.

Next steps

• Editing your app — the changes that create checkpoints
• Fixing errors — when to roll back rather than push on
• Environments — why your live app is unaffected