# File History

> Per-note version history in the cloud — open File history on any note to see every saved version and restore or merge in old content.

Every saved version of a note is preserved automatically in Basic Memory Cloud. Open **File history** on any note to see its full timeline, compare an earlier version side-by-side with the current one, and apply changes back into the live note. It's the fast, per-note answer to "I want to undo something" — distinct from [Snapshots](/cloud/cloud-snapshots), which are workspace-wide point-in-time backups.

<note icon="i-lucide-history">

File history is a cloud feature. Versions are created automatically on every save — no setup, nothing to turn on.

</note>

<docs-video alt="Opening File history and restoring an earlier version of a note" poster="/videos/posters/docs-file-history.png" src="/videos/docs-file-history.mp4">



</docs-video>

---

## Open File history

In the [web app](/cloud/web-app), open the note you want to look back at, then click the **File history** icon (clock) in the note's toolbar.

<theme-image alt="File history button in the note toolbar" dark="/screenshots/cloud-app/v2-file-history-button-dark.png" light="/screenshots/cloud-app/v2-file-history-button-light.png">



</theme-image>

A modal opens with two panes:

- **Left**: the timeline of versions, newest first. Each row shows the timestamp, a short version ID, and the file size. The latest version is marked **Current**.
- **Right**: a side-by-side **diff** between the version you've selected (read-only, on the left of the diff) and the current note (editable, on the right).

<theme-image alt="File history modal with version timeline and diff" dark="/screenshots/cloud-app/v2-file-history-dialog-dark.png" light="/screenshots/cloud-app/v2-file-history-dialog-light.png">



</theme-image>

Select a version on the left to load it into the diff. Use **Load more** at the bottom of the list if you have a long history.

---

## Restore (or merge) an old version

The diff view isn't just a viewer — the right side is a live, editable draft of what your note will become when you click **Apply**.

You have two ways to bring old content forward:

- **Pick exactly what you want.** Use the `>` revert controls in the diff to accept individual changes from the old version into the draft.
- **Edit the draft directly.** Type into the right pane to make manual tweaks before applying.

When the draft looks right, click **Apply**. That saves the merged content as a **new** version — it doesn't overwrite or rewind history. Your existing versions stay intact, with the freshly applied content sitting on top as the new Current.

<note>

**Apply creates a new version, not a rollback.** If you change your mind, just open File history again and merge back from any earlier version. Nothing's ever lost.

</note>

### When Apply is disabled

A few states will gray out the **Apply** button:

- **Unsaved edits in the main editor.** Save your current draft first, then apply from history.
- **"File history is catching up."** Your most recent save hasn't reached the storage layer yet. Wait a moment and refresh.

Apply can also **fail after clicking** with *"Current file version changed; refresh before applying."* — someone (or something) wrote the note while you were merging. Refresh history and reapply on top of the new current version.

---

## Who can see and use it

- **View history** — anyone with read access to the note (Viewer and above).
- **Apply a version** — anyone with edit access (Editor and above). Viewers can browse history but can't write.

In a [team workspace](/teams/about), this follows the project's normal access rules.

---

## File history vs. Snapshots

<table>
<thead>
  <tr>
    <th>
      
    </th>
    
    <th>
      File history
    </th>
    
    <th>
      <a href="/cloud/cloud-snapshots">
        Snapshots
      </a>
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <strong>
        Scope
      </strong>
    </td>
    
    <td>
      One note at a time
    </td>
    
    <td>
      The whole project / workspace
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Created
      </strong>
    </td>
    
    <td>
      Automatically on every save
    </td>
    
    <td>
      Automatically daily + manually on demand
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Use it for
      </strong>
    </td>
    
    <td>
      "I want to undo the last few changes to this note"
    </td>
    
    <td>
      "I want to roll back a bulk reorganization" or "I deleted a folder by accident"
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Restore creates
      </strong>
    </td>
    
    <td>
      A new version of the note
    </td>
    
    <td>
      Files written back into the live project
    </td>
  </tr>
  
  <tr>
    <td>
      <strong>
        Best for
      </strong>
    </td>
    
    <td>
      Granular per-note recovery
    </td>
    
    <td>
      Project-scale recovery
    </td>
  </tr>
</tbody>
</table>

Both work alongside each other — start with File history for a single note, fall back to a Snapshot when you need a bigger rollback. See [Restore Lost Content](/cloud/restore-lost-content) for a recovery decision guide.

---

## Under the hood

File history is built on **object versioning** in our underlying storage (Tigris). Each save writes a new object version, so every meaningful state of every note is preserved — without any extra storage choreography on your part.

For more on the architecture, see the Tigris case study: [Own Your AI Context with Basic Memory](https://www.tigrisdata.com/blog/case-study-basic-memory/).

---

## Related

- [Restore Lost Content](/cloud/restore-lost-content) — when to use File history vs. Snapshots
- [Cloud Snapshots](/cloud/cloud-snapshots) — workspace-wide point-in-time backups
- [Web App](/cloud/web-app) — the editor and surrounding UI
- [Teams](/teams/about) — permissions in a shared workspace