History and restore

What History records

History lists durable project file snapshots backed by Git commits. Completed agent work and explicit restore operations can add versions. The newest entries load first, and older pages appear as you continue through the list. History is separate from the messages stored in each chat.

One request can create several versions. A version saved before the agent publishes is titled Before publishing; if the agent changes files afterward, the final version uses your request as its title. For example, publishing a site and then deleting uploaded source files creates two different versions. The Published marker identifies the version serving visitors.

Stopping a task also saves the changes made so far as a version marked Interrupted. Wait for stopping to finish before opening that version. Its title uses your original request. This preserves the files; it does not mean the unfinished application has passed all checks or is ready to publish. Continue the task when more work is needed.

History includes editable source and migration files, application configuration, the managed database owner binding, and project environment-variable scopes. Environment values are not rolled back. It does not snapshot:

• PostgreSQL data;
• object storage;
• declared application volumes;
• third-party services or other external state.

Treat those systems according to their own backup and migration requirements.

Inspect an earlier version

View-only members can open earlier versions and return to the current version while the agent is idle. Select a timeline row to preview it. Each row shows a title with its date and summary below, and the restore icon is on the right. Current, previewed and published versions retain distinct markers. The separate restore button stays visible but disabled without Editor or Full access permissions.

Select a version to inspect its source through the existing development Preview. The shared workspace temporarily shows that commit; all project members see the same selection. This does not move the main branch or create a separate runtime. Agent submissions are blocked while an older version is selected. The database, stored files, volumes, and current environment values remain live, so interacting with an old page can still change current data.

Leaving History while an earlier Preview is selected asks for confirmation. Continuing restores the current source in the shared workspace and returns to the live application. It creates no restore commit and does not rewind external data.

Restore project files

Choose the explicit restore action only after reviewing the boundary above. You can start it from History, and Amazi can perform the same protected soft revert when you ask it to restore a recorded Git commit. Amazi creates a new forward commit whose source tree and application configuration match the selected version; it does not move the project branch backward. Applications added after that version become pending deletion so production resources are not destroyed implicitly. Databases, environment values, stored objects, volumes, and external services remain unchanged, so an older source version may require follow-up work to remain compatible with current data. A mixed or partially modified worktree fails closed instead of guessing which edits to overwrite.