DESKTOP BACKUP / EARLY ACCESS
Your files keep moving.
Your history stays.
A local-first desktop backup concept that records changes, keeps readable versions, and sends them to repositories you control.
No command-line setup required
Original folders remain untouched
Private destinations by default
Dashboard
History
Problems
Schedule
Destinations
NextHive — 5 profiles · Today, 09:04
Run all
Documents
Personal
24 changed
Verified
Backed up
Client work
Work
8 changed
Verified
Backed up
Brand assets
Work
3 changed
Hashing
Running
Photos
Personal
Queued
Waiting
Queued
Research
Personal
No changes
Current
Backed up
0
folders rewritten
SHA-256
change verification
Private
destinations by default
One lock
per backup profile
THE PROBLEM
Manual backups become a quiet liability.
Duplicate versions pile up until nobody knows the latest one.
Loose archives hide what changed and when it changed.
Sync tools can replace files without preserving a useful history.
Failures are often discovered only when recovery becomes urgent.
Desktop › Backups (manual)
proposal-final.docx
12 Mar
proposal-v3.docx
03 Apr
proposal-FINAL.docx
03 Apr
proposal-copy.docx
unknown
archive-old.zip
contents unknown
Which copy should you trust?
PRODUCT SCREENSHOT
WITH THE APP
The app handles the routine. You keep the proof.
Scheduled and manual runs create the same readable history.
Every run becomes a version you can inspect from another machine.
Progress is shown as real stages instead of an invented percentage.
One dashboard surfaces changes, failures, and the next scheduled run.
HOW IT WORKS
Set it once. Keep the timeline growing.
Each profile defines what to watch, where versions go, and when the job should run. The interface keeps that contract visible.
STEP 01
Choose what matters
Start with documents, project folders, or any directory worth protecting.
Documents
Client work
Brand files
build cache
STEP 02
Scan only what changed
Fast metadata checks skip stable files so hashing focuses on real changes.
metadata compare · 8,241 files
unchanged skipped · 8,210
rehash changed · 31 files
SHA-256 verified · 31 / 31
source remains read-only
STEP 03
Commit and confirm
A run is complete only after the destination accepts the new version.
commit 2026-08-27
31 files
push → private-repo
accepted
Confirmed by destination
Documents
Client work
Design
Finance
Photos
Research
02:00
Scheduled run missed
machine asleep
09:04
Caught up after wake
31 files
09:04
Readable version written
commit
09:05
Destination accepted push
confirmed
SCHEDULING
Automate the routine you never remember.
Missed runs can catch up when the machine is available again, while the tray keeps manual controls close without reopening the full app.
Catch-up scheduling
Resume a missed routine after wake.
Quiet tray operation
Pause or run without opening the full window.
Visible problem files
Retry or exclude an exact item with context.
YOUR DESTINATION
Your account. Your repository. Your history.
Connect a provider you already use, pick an existing private repository, or create a new private destination for the profile.
AVAILABLE NOW
G
GitHub
G
GitLab
G
Gitea / Forgejo
C
Codeberg
PLANNED
G
Google Drive
Planned
Y
Yandex Disk
Planned
M
MEGA
Planned
S
SFTP / FTPS
Planned
EVERY DESTINATION GETS
Large-file handling
Permission checks before sync
Private visibility by default
Credential vault storage
ACCURACY
Verified, or it does not count.
A backup should report concrete stages and real changes, then mark success only after the destination confirms the new version.
Metadata checks avoid repeating expensive work.
Changed files receive strong content verification.
Version folders remain readable without the original application.
A
design/launch-notes.md
+ 18 KB
M
src/features/sync.ts
verified
D
archive/old-draft.pdf
removed
Destination confirmed the new version
FAQs
A compact place for the questions people usually ask before trying the product.
What is this product?
A desktop-first backup experience designed around readable versions and private destinations.
Does it rewrite my folders?
The template presents the product as read-only at the source and versioned elsewhere.
Do I need a separate Git install?
The interface is designed to keep repository mechanics behind the application.
Where do versions live?
They can be sent to private repositories owned by the person using the app.
How is security communicated?
The design separates filesystem work, credentials, and the web-facing interface.
SECURITY BY BOUNDARY
Secrets stay isolated. Files stay out of the web layer.
The visual system makes the trust boundary part of the product story: sensitive work stays native while the interface remains narrow and inspectable.
Private repository access is not the same thing as end-to-end encrypted storage.
Tokens in the OS vault
Typed native commands
Private destinations
No shell-built Git
BYTES OF YOUR FILES STORED ON APP SERVERS, TO DATE
0
0
0
,
0
0
0
,
0
0
0
In this concept, backups travel directly from the machine to destinations the user owns; the marketing layer never becomes a storage service.