> ## 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.
# Checkpoints
> Automatic and manual restore points that capture your project state so you can always roll back
A **checkpoint** is a complete snapshot of your project's state at a moment in time. Hiveku creates checkpoints automatically as you work, and you can also create them manually whenever you want to lock in a known-good state. Any checkpoint can be restored with a single click.
Checkpoints are project-wide. If you only need to revert a single file, use **Version History** (right-click any file in the file tree).
## When checkpoints are created
| Trigger | Created automatically | Notes |
| --------------------- | ------------------------------------------------------ | ----------------------------------------------------------------------------------------------------- |
| **AI chat session** | Yes -- before each AI turn that may write files | Lets you undo the AI's changes wholesale |
| **File save** | Yes -- throttled to once every 5 minutes | Captures edits made directly in the code editor or pulled from GitHub |
| **Before deployment** | Yes | Snapshots files + database + assets before each deploy so you can roll back if the new version breaks |
| **Before restore** | Yes (safety backup) | Hiveku snapshots your *current* state right before applying a restore -- you can always undo an undo |
| **Manual** | No -- you trigger it | Available on the **Hosting** page. Useful when you want to mark a milestone before a risky experiment |
| **External agents** | Yes -- when agents call the Hiveku API to make changes | Same lifecycle as AI chat checkpoints |
Identical-content checkpoints don't pile up. If your project hasn't actually changed since the last checkpoint, Hiveku reuses the existing one instead of creating a duplicate. Manual checkpoints always create a new entry so you can mark moments deliberately.
## What's captured
| Captured | Not captured |
| ----------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ |
| All current files in your project (code, content, configuration) | Build outputs (Hiveku regenerates these on deploy) |
| Binary assets (images, fonts, videos) referenced by your project | The currently-running preview container |
| Database schema and rows -- for managed databases and BYOD databases with backups enabled | Custom domain DNS settings |
| File metadata (path, size, version number) | Environment variables and secrets (managed separately on the **Hosting** page) |
| The checkpoint's trigger reason and your description | Deployment history (kept separately) |
Environment variables and secrets are **not** included in checkpoints. If a restore depends on a specific value for an environment variable, set it back to that value on the **Hosting > Environment Variables** page after restoring.
## How to view and restore checkpoints
From your project, navigate to **Hosting**. The Checkpoints section lists every checkpoint for the project, newest first, with the trigger reason and timestamp.
Each entry shows when it was created, what triggered it, how many files it contains, and the total size. Click **Preview** to see a diff of what restoring it would change versus your current state.
Click **Restore**. Hiveku first creates a **pre-restore safety backup** (so you can undo this restore if you change your mind), then applies the checkpoint:
* All files in the checkpoint are restored to their captured content
* Asset references are restored to their captured versions
* If the checkpoint included a database backup, the database is restored
Once the restore completes, refresh your preview to confirm the state looks right. If anything is off, you can restore the safety backup that Hiveku just created.
Restores work the same way regardless of when the checkpoint was created. A checkpoint from a year ago restores identically to one created five minutes ago.
## How to create a checkpoint manually
Navigate to **Hosting**. Find the Checkpoints section.
Click **Create Checkpoint**. Optionally add a description -- a short note like "before refactoring auth" makes it easy to find later.
Creating a checkpoint takes a few seconds for small projects and up to a minute for large ones. You'll see a confirmation when it's saved.
## What checkpoints do not do
Checkpoints are not a substitute for deploying. Restoring a checkpoint only affects the project files inside Hiveku -- your live website at your custom domain or production URL is unchanged until you deploy again.
| Concern | Reality |
| ------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **"Will restoring a checkpoint roll back my live site?"** | No. Restore brings your *editor* and *preview* back to that state. To update the live site, redeploy. |
| **"Will restoring affect my domain or DNS?"** | No. Domain config and DNS records are managed separately and aren't part of a checkpoint. |
| **"Are old checkpoints kept forever?"** | No. Hiveku applies a tiered retention policy: very recent checkpoints are kept densely, then weekly, then monthly. Most projects never notice -- if you need the most recent state, it's always available. |
| **"Will a checkpoint capture data inside my live database?"** | Only for projects with a managed database or BYOD database with backups enabled. Otherwise the checkpoint captures files only. |
| **"Can I restore just one file from a checkpoint?"** | Use **Version History** on the file instead -- it's the per-file equivalent and faster for single-file rollbacks. |
## Checkpoints and deployments
Each deployment is anchored to a checkpoint created right before the deploy started. This means:
* The **Deployments** page shows the checkpoint each deploy was made from
* Rolling back a deployment is equivalent to restoring its anchor checkpoint and redeploying
* You can compare what changed between two deployments by diffing their anchor checkpoints
See [Deployments](/publishing/deployments) for more on the deploy + rollback flow.
## Storage and performance
You don't have to think about checkpoint storage -- Hiveku handles it. For curious users:
* The checkpoint catalog (when each one happened, what triggered it, how many files it covers) lives in your project's metadata
* The actual file and asset content lives in Hiveku's checkpoint storage, separate from your project database
* This separation means many checkpoints can be retained without slowing down your project's database queries
Restore speed depends mostly on project size. A typical project (a few hundred files, a few MB of assets) restores in 5-15 seconds. Very large projects (thousands of files, hundreds of MB of assets) can take a minute or two.
## Common questions
The auto-save throttle is 5 minutes. If you're editing actively, you get a fresh checkpoint roughly every 5 minutes. If you're not editing, none are created. Other triggers (before a deploy, before a restore, AI chat sessions) bypass the throttle.
Yes. Click **Preview** on a checkpoint to see what restoring it would change against your current state. For deploy-to-deploy diffs, use the diff view on the **Deployments** page.
Hiveku's tiered retention keeps recent checkpoints densely, then thins to weekly and monthly snapshots over time. You will not lose access to recently restorable points -- only highly redundant old ones get pruned.
Hiveku automatically creates a pre-restore safety backup right before applying any restore. To undo: open Checkpoints, find the one tagged `pre-restore`, and restore it. Your state goes back to where it was before the bad restore.
No. Project configuration like custom domains, environment variables, analytics integrations, and email setup is managed separately and isn't part of a checkpoint. Files and asset content are captured; project-level settings are not.
Yes -- agents using the Hiveku API can create and restore checkpoints the same way the UI does. Every API call that modifies project files automatically creates a checkpoint first so changes can be undone.