Versions and going back

Every deploy creates a new version. The last 10 builds of each app are kept ready to go back to, on every plan; an older version can no longer be put back, though its code can still be cloned while its source is kept (the newest five versions, and any from the last 30 days).

Seeing versions

In the dashboard, open the app and choose Versions. Each row says when it was made and by whom ("by Claude", "by the dashboard"), and whether it is live. From a terminal: npx uarpie versions.

Deploying when nothing has changed

Running the deploy again when the app's files, settings and deploy.json are all the same as the live version does nothing and costs nothing: no new version is made. The same app is still built again when the platform itself has been updated since the live version was built, so every app gets the platform's fixes, and when a setting the app reads while it is being built changed after it was built. Either way a new version appears in the list.

Going back

Click Go back to this, or ask your AI. Going back takes about half a minute: the older version is started again and checked, then the address points at it. Nothing is rebuilt.

Your data stays as it is

Going back puts back the code only; the database keeps today's data. If a later version changed the database's shape (added a table, renamed a column), the older code runs against the newer data, which is usually fine when the change only added things. If it is not, go forward again the same way, or ask your AI to fix it forward.

Getting the data back from before a change is not something you can do yourself.

Watching a deploy

Most people never need to. For those who want to: each version has a trace, reachable from Versions ("Trace") or from the Updating... banner while a deploy is running. It shows each step with its timing, and the build output once the build has finished. If a deploy failed, the trace opens with What happened and the fix first, and the raw output below it.