Skip to main content
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

TriggerCreated automaticallyNotes
AI chat sessionYes — before each AI turn that may write filesLets you undo the AI’s changes wholesale
File saveYes — throttled to once every 5 minutesCaptures edits made directly in the code editor or pulled from GitHub
Before deploymentYesSnapshots files + database + assets before each deploy so you can roll back if the new version breaks
Before restoreYes (safety backup)Hiveku snapshots your current state right before applying a restore — you can always undo an undo
ManualNo — you trigger itAvailable on the Hosting page. Useful when you want to mark a milestone before a risky experiment
External agentsYes — when agents call the Hiveku API to make changesSame 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

CapturedNot 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 projectThe currently-running preview container
Database schema and rows — for managed databases and BYOD databases with backups enabledCustom 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 descriptionDeployment 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

1

Open the Hosting page

From your project, navigate to Hosting. The Checkpoints section lists every checkpoint for the project, newest first, with the trigger reason and timestamp.
2

Pick a checkpoint

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.
3

Restore

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
4

Verify

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

1

Open the Hosting page

Navigate to Hosting. Find the Checkpoints section.
2

Create checkpoint

Click Create Checkpoint. Optionally add a description — a short note like “before refactoring auth” makes it easy to find later.
3

Wait for confirmation

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.
ConcernReality
”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 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.