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.

Tasks that only inspect the project do not create a new version when its files and settings remain unchanged. A settings-only version can have +0 / −0 file changes: those counters measure source lines, not application settings.

If an agent task fails after making changes, Amazi saves those changes in History before another task starts. The task still shows an error, and the saved version may contain unfinished or unverified work. Choose Continue in the chat to carry on from the saved files. A failure before any changes does not create an empty version.

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.

Stop tracking files or remove them from History

In the project's chat, specify exact file or folder paths and which result you want:

• Stop tracking, keep the files: the files stay in the current workspace but are excluded from future automatic versions and source exports. Earlier versions retain their contents.
• Remove from all past versions: the project owner can ask Amazi to purge those paths from History. Current workspace files stay in place, but History can no longer recover their old contents. New automatic versions and source exports also exclude them.

Return to the current version before starting either operation. Disconnect GitHub before purging history. This does not remove copies from GitHub, other projects, existing publications or backups. Renamed copies need their own exact paths. Existing publications keep serving their current files; the old Published marker may disappear after a purge until you publish again. Removing a file from history is not a way to change a running publication.

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.