CherryTree

Last reviewed Sep 13, 2026 · 746 words

Everything CherryTree knows lives in one file. Copy that file and you have a complete backup; encrypt it and you have a password-protected notebook; put it in a Syncthing folder and you have multi-machine notes with no server at all. That single-file design is why a desktop app from 2009 still has 3,941 stars and a loyal following among sysadmins and security people, and it is also the source of the one way it will bite you.

What CherryTree is, and is not

It is a desktop application, C++ and GTK, running on Linux, Windows and macOS on about 128 MB of RAM. There is no server component, no web interface and no mobile app. Notes live in a tree: nodes and sub-nodes, each holding rich text, images, tables, and code blocks with syntax highlighting for dozens of languages. A node can be set to be entirely code, which is why so many people use it as a runbook of commands and configs with paste-ready snippets. If you want a browser tab or a phone app, stop here and look at Joplin or Trilium; CherryTree is for the person who lives on one or two workstations.

Four file formats, and which to pick

CherryTree saves to .ctb (SQLite), .ctd (XML), and password-protected versions of each, .ctx and .ctz. SQLite is the sensible default: it loads faster on large trees and writes only what changed. XML is human-readable and diff-friendly, which matters if you keep notes in git. The encrypted formats wrap the file in 7-Zip AES encryption with your password, and the protection is real, with the usual caveat that the decrypted working copy sits in a temp directory while the app is open. Losing the password loses the notes; there is no recovery route. Coming from elsewhere is easier: the import menu reads Zim, Tomboy, KeepNote and Treepad notebooks, plus folders of plain text or HTML, and a migration in usually takes minutes rather than an evening.

Syncing without corrupting the file

The catalogue lists "no built-in sync" as a con, and the fix everyone reaches for is Syncthing. It works, with one rule: never have the file open on two machines at once. CherryTree writes the whole SQLite file, Syncthing sees a change mid-write on the other side, and you get a conflict copy or, worse, a half-synced database. Close the app before you walk to the other machine, turn on Syncthing's file versioning so a bad sync is recoverable, and keep .ctb rather than XML for sync because the smaller write window shortens the race. Nextcloud or any file sync behaves the same way; the problem is the single-file design, not the tool.

Backups are a copy command

This is the strength. A nightly cron line that copies the .ctb to a dated filename, plus CherryTree's own automatic backup setting (it keeps a configurable number of previous versions next to the file), covers most disasters. Export to HTML, PDF or plain text from the menu when you need a format you can read in 15 years without the app. The full tree exports as a folder of HTML pages, which is a better long-term archive than most note apps offer.

Who actually runs it in 2026

Two groups. The first is people who want structured, hierarchical notes with heavy code content and refuse to run a server for it; the Kali Linux community adopted CherryTree for engagement notes years ago, and it is still standard there. The second is people who tried Joplin, disliked the Electron footprint, and wanted something that starts in under a second. If neither is you, the notes category is full of apps with sync built in, and the notes you own post walks through the server-backed options.

What I'd do

One .ctb file per major subject rather than one giant tree, so a sync conflict damages less. Syncthing with versioning between desktop and laptop, app closed before switching. Automatic backups on, plus a weekly HTML export to the same folder as the rest of my backups. Used like that, CherryTree is the fastest, most portable notebook I have run. The moment you need it on a phone, move to Joplin and import the HTML export; do not fight the tool into a shape it was never built for.