GitDocAI automatically backs up your documentation on every publish, and lets you restore any previous state with one click. This page covers the auto-backup model, how to configure an external backup repository, and the restore flow.
Automatic backups on publish
Every time you click Publish, GitDocAI snapshots the full state of your documentation — every section, every page, every theme setting, every version — and writes it to your backup history before the live site is updated. There's nothing to configure: auto-backup is on by default.
Each entry in the backup history records:
The publish that created it (date, who triggered it).
A hierarchical summary — version → section → page counts at the moment of capture.
A unique
backup_idyou can use to restore directly.
Because backups run in the background after publish kicks off, they never delay your readers seeing the new content.
Configuring a backup repository
By default backups live inside GitDocAI's storage. For an additional layer of protection — or to keep an off-site copy in version control — you can configure a backup repository: a GitHub repo where GitDocAI will mirror each snapshot in a human-readable layout.
From the Backups tab of the dashboard, choose Configure backup repository and pick any GitHub repo your installation has access to. An empty repo works best.
GitDocAI uses the same GitHub installation that powers source ingestion, so no separate auth step is needed.
From the next publish onward, each snapshot is committed to the configured repo. The history view in the dashboard remains the canonical place to inspect and restore — the repo is a backing store.
Snapshots in the backup repo use a human-readable layout (MDX per page, JSON for structure and config) — so you can diff them in GitHub if you want to audit what changed publish-over-publish.
Browsing backup history
The Backups page in the dashboard sidebar is split into two tabs:
Configuration — where you set up or change the backup repository.
History — the full list of snapshots, newest first, with the hierarchical summary inline so you can see at a glance which publish corresponds to which state.
Each entry can be expanded to drill into its section/page tree before you decide whether to restore.
Restoring a previous publish
Restoring overwrites the current draft of your documentation with the content from a chosen backup. Your published live site is not touched until you publish again — restore is a safe operation you can preview first.
Go to Backups → History in the dashboard sidebar.
Use the summary to identify the publish you want to roll back to. Expand the entry to confirm the structure looks right.
GitDocAI loads the snapshot's content into your draft. You'll see the editor refresh with the restored sections and pages.
Open a few pages to confirm. When you're satisfied, hit Publish to push the restored state to readers.
Restore replaces every section, page, and config setting in the current draft. Any unpublished work-in-progress is overwritten and not recoverable from the backup history (it was never captured, because backups are taken at publish time).
If you only need to recover a single page rather than the entire doc, expand the snapshot to view its content and copy the affected page back manually instead of restoring the whole tree.
Permissions
Admin and Editor roles can view history and trigger a restore.
Only Admin can change the backup repository configuration.
Viewers see history in read-only mode without the restore action.
Related
Configuring and Publishing — for the publish lifecycle that triggers each backup.
Re-sync & Pending Changes — when you want to roll forward from upstream source changes rather than roll back to a previous publish.