> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hiveku.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Project history
> Restore points back up your site's pages, images and data. Compare one with now, preview it, restore it, or go back to any moment in time.
**Project history** is your site's timeline of **restore points**. A restore point backs up everything: pages, images and uploads, and, for a project with a database, its data. Open it from the **Project history** tab in the editor.
Project history and [versions](/editor/versions) do different jobs:
* A **version** is a saved copy of your pages. Go back to one on the **Branches** tab. Versions are saved for you every few minutes, on Your site and on every branch.
* A **restore point** also brings back images, uploads and data, and can take your site back to any moment in time.
Project history restores **Your site**. On a branch, go back with the branch's own versions; images and uploads are shared by every branch.
## When restore points are saved
Hiveku saves a restore point on its own:
* Before and after each publish
* Once a day
* Before a restore or a rollback, so you can come back to where you were
* Before a bulk replace or an import
* Before an image or other upload is added, deleted or renamed, because versions do not hold uploads
* Before each AI request, on a site with a database: a version holds pages only, so a restore point is the only way to bring the data back
Since 11 October 2026, two automatic restore points are skipped where versions do the job:
* The editor's restore point every few minutes of editing, on every site: versions are saved when you pause.
* The restore point before an AI request, on a site without a database, when the request has a version to go back to: **Undo this turn** in the chat goes back to the version saved before the request. On a site with a database, it is still saved.
### Save a restore point yourself
**Save restore point** in the Project history header saves one now. The name is optional. Save one before a risky change you may want to undo, data included.
## Look at a restore point
Each restore point says what kind it is, when it was saved, and its name.
**Compare with now** ("Show what is different on your site now") lists the code files that differ between the restore point and your site now:
* "In the restore point but not on your site now. Restoring brings it back."
* "Added after the restore point. Restoring keeps it."
* "Different now from the restore point"
Each file opens a side-by-side view. Images and uploads are not compared here.
## Preview a restore point
The preview button starts a separate preview of the restore point, so you can click through the site as it was. It takes 30 to 60 seconds to start, and your site's own preview is not touched. You can cancel it from Project history at any time.
The preview runs with your live database and services, so a form sent or a purchase made in it is real.
## Restore
There are two ways to restore a point, and they treat files made after it differently:
* **From its preview**, apply it: "Apply this restore?" says "Your site goes back to what you just previewed." and "Files CREATED after *the point* are REMOVED, so your site matches the preview you just looked at." Click **Apply restore**.
* **Straight from the list**, click **Restore**: "Files CREATED after the restore point are KEPT (not deleted), so you may need to remove them yourself."
Either way, your site as it is now is saved first as a restore point, so you can come back to it.
When the restore is done, Hiveku says how it shows in your versions:
* "Restored and saved as a version."
* "Restored. Nothing was different, so there is no new version."
* "Restored. It will show in your versions shortly."
* "Restored. It is part of your latest version."
A restore changes Your site, not the live site. Publish when you are ready for visitors to see it.
If Hiveku cannot save the return point first, it stops and asks: "Could not save a return point for your current state". Continuing with **Restore anyway** means the restore cannot be undone, so stopping is the safer choice.
## Restore to a time
**Restore to a time…** goes back to any moment, not only a saved restore point. Pick a date and time in the past. "All files and images go back to the closest copy stored at that time." Your site as it is now is saved first, as a pinned restore point.
By default, files made after that moment stay: "Files created AFTER that moment are KEPT — the result is a mix of both states, not an exact copy of that moment."
Tick **Match that moment exactly** ("Also removes files, images and uploads created after it") to remove them too: "Files, images and uploads created AFTER that moment WILL BE REMOVED, so your site matches that moment exactly."
If some files could not be recovered, Hiveku says so ("Partial restore: … could NOT be recovered") and asks you to check your site before publishing.
## One file: earlier copies
To bring back one file, open it in the code editor and click **History**. It lists the file's earlier copies on Your site:
* **Compare with the file now**
* **Bring it back**: the earlier copy replaces the file, and the change is saved as a version.
* **Delete it**: removes an earlier copy you no longer need. A copy that a restore point still needs is kept.
Earlier copies belong to Your site, so on a branch the **History** button is not shown.
## Roll back a deployment
**Hosting › Deployment History** lists each deploy. **Rollback** brings your project files back to that deploy ("Roll back your project files to this deployment?", **Roll back files**), with images and assets when a restore point holds them. It changes your project only: the live site keeps serving the current build until you deploy again. A safety backup is saved first.
To change what visitors see right away instead, use **Instant rollback (live traffic)** on the Hosting page: it points one environment at a build it deployed before, without a rebuild, and leaves your files as they are. See [Deployments](/publishing/deployments#put-the-earlier-build-back-live).
## What restore points do not cover
* Environment variables and secrets: set them on the project's **Environment Variables** page (see [Environment variables](/how-tos/env-vars)).
* Domains and DNS.
* The live site: restoring never publishes.
## Who can restore
Seeing Project history needs **Websites › Projects: View**. Saving a restore point and restoring need **Websites › Projects: Create**. Deleting an earlier copy needs permission to delete files in the project. See [Permissions](/settings/permissions).
## From AI tools
AI tools reach Project history too: `history_restore_to_time` goes back to a moment, `history_preview_restore` previews a restore point, `checkpoint_create` saves one, and the `checkpoint_*` and `project_checkpoint_*` tools list and restore them (`project_checkpoint_restore_dry_run` shows what a restore would change first). `project_file_versions` and `project_file_restore` work with one file's earlier copies. For pages only, the tools prefer [versions](/editor/versions) (`project_vcs_rollback`).
## Common questions
No. A restore changes Your site. Visitors see it after you publish.
Yes. Your site is saved as a restore point before each restore, so you can restore that one.
For pages and code, roll back a version on the **Branches** tab: it is quick and keeps every newer version. Use a restore point when you also need images, uploads or data back, or a moment in time between versions.
No. Project history restores Your site. On a branch, roll back one of the branch's versions.
Checkpoints are now called restore points, and they live in the editor's **Project history** tab.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.