Dnote: a CLI notebook that keeps your notes in one SQLite file
A simple command line notebook
At a glance
- What is it?
- Dnote is a Go command line notebook that stores everything in a single SQLite file and offers optional self-hosted sync. It fits engineers who live in a terminal and want searchable notes without a hosted service.
- Who is it for?
- Adopt Dnote if your notes are short, text-heavy, and you want them in a file you can copy, back up, or grep without a service account. Skip it if you need rich formatting, images, or multi-user collaboration, since nothing in the README or release notes suggests those exist.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 53 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Dnote targets: notes that survive the terminal session
Most note tools assume a browser or a desktop app. If you spend the day in a shell, the friction of switching context to record one command or one config fragment is often higher than the value of the note. Dnote's pitch is that the note-taking step stays inside the shell: one binary, no runtime dependencies, and a storage format you can inspect with standard tools. The README states the project has existed since 2017, which matters less as a maturity signal than as an indication that the command surface has had time to settle. The audience is narrow and clearly defined: developers, sysadmins, and anyone who already keeps a scratch file of commands and wants structure (books, search, optional sync) without adopting a hosted product. It is not aimed at people who want to clip web pages, embed images, or share a notebook with a team.
Books, a SQLite file, and an optional server in the middle
The data model is deliberately flat. Notes belong to a book, and a book is just a named grouping; the README example uses linux as the book name. Notes are stored in one SQLite file, which the README describes as portable, searchable, and under your control. That single-file design is the core architectural decision, and it explains most of the rest: full-text search runs locally against that file, and sync is not a prerequisite for using the tool. Sync, when enabled, goes through a server that the README describes as a binary with SQLite embedded, so there is no separate database to install or tune. The server exposes a REST API, which means the CLI is not the only possible client. The flow is therefore: write locally, search locally, and push to your own server only if you want the same notes on another machine. Nothing in the supplied material describes conflict resolution, so how two devices editing the same note reconcile is something you would need to determine from the documentation or the source before relying on it.
Getting it running: install script, Homebrew, or a release binary
Installation has three documented paths. The first is a shell installer: curl -s https://www.getdnote.com/install | sh. The second is Homebrew on macOS: brew install dnote. The third is downloading a binary directly from the GitHub releases page. The README lists Linux, macOS, FreeBSD, and Windows as supported platforms. Note that the pipe-to-shell installer is the fastest route and also the one most likely to be blocked by a corporate policy; the release binary avoids that entirely and is the option worth preferring if you cannot read the script first. The core commands are small enough to memorize. dnote add linux -c "Check disk usage with df -h" adds a note to the linux book, and omitting -c launches your editor instead, which is the path you want for anything longer than a line. dnote view linux prints the notes in that book. dnote find "disk usage" runs full-text search. dnote sync pushes to the server. If you want the server, the README gives a compose.yml with the image dnote/dnote:latest, container name dnote, port mapping 3001:3001, the volume ./dnote_data mounted at /data, and restart: unless-stopped, started with docker-compose up -d. The README also points to a manual installation guide for running the server as a plain binary. The only configuration key visible in the supplied material is that /data mount, so treat the volume path as the thing to get right before anything else.
Where Dnote stops being the right tool
The storage model is also the limitation. One SQLite file is excellent for a single user on one machine and awkward the moment two people need to edit the same content, because there is no mention of permissions, sharing, or per-book access control anywhere in the README. Rich content is another boundary: the examples are plain text passed through -c or typed into $EDITOR, and nothing suggests attachments, images, or rendered markdown. If your notes are mostly screenshots and diagrams, this is the wrong tool. Search is full-text over your own file, which is fast and private but not semantic; "disk usage" matches the literal string, not the concept of checking free space. The server adds an operational surface you now own: a container, a port, a volume, and upgrades. The release history shows server and CLI versioned separately (server-v3.0.0 and cli-v0.16.0 in late 2025), which is a reasonable design but means you should check compatibility between the two before upgrading one side. Finally, the README does not state what happens when sync fails mid-write or how the local file behaves if the server is unreachable; if offline-first behavior matters to you, confirm it rather than assuming it.
How Dnote differs from a git-tracked notes directory
The obvious alternative is a directory of markdown files in a git repository, which many engineers already have. The difference is in the retrieval path, not the storage. With plain files you get history, diffs, and code review for free, but search means remembering to run grep or ripgrep with the right flags, and there is no notion of a book unless you create directories and enforce that convention yourself. Dnote trades that flexibility for a fixed command set: add, view, find, sync. You give up diffs and merge tooling; you gain a single queryable file and a sync command that does not require you to resolve a merge conflict by hand. If your notes are mostly one-liners you look up weeks later, the Dnote model is the better fit. If your notes are long documents you revise, the git directory wins, because version control is the feature you actually need and Dnote's README does not describe revision history for notes. A hosted notes service is the other alternative, and the trade is the usual one: less setup, more dependence on someone else's account, export format, and pricing.
Maintenance cost, licensing, and what the release cadence implies
Dnote is Apache-2.0 licensed. That is a permissive license, which generally means you can use, modify, and redistribute it, including in commercial settings, provided you keep the required notices; it also includes an explicit patent grant. This is not legal advice, and if you plan to fork or ship it inside a product, read the LICENSE file in the repository rather than a summary. Operationally, the cost splits in two. The CLI is a single binary with no dependencies, so upgrades are a download and a replacement, and there is no migration step described in the README. The server is where maintenance accumulates: a container image tag (dnote/dnote:latest), a volume to back up, and a REST API that other clients may depend on. The supplied release list shows server-v3.0.0 as a major version bump, which conventionally signals breaking changes; if you run a server, pin the image tag rather than tracking latest, and read the release notes for that version before moving. The last push date on the repository is recent, so the project is not dormant, but the material here does not include contributor numbers or a support commitment, so treat long-term maintenance as an open question you resolve by watching release frequency over a few months.
Who should adopt Dnote, and what to check first
Dnote suits a single developer or sysadmin who wants short text notes, values owning the file, and is comfortable running a container if sync is needed. The install is one command, the storage is one file, and the command set is small enough that there is little to learn. It does not suit teams needing shared notebooks, anyone whose notes are primarily visual, or anyone who needs revision history per note. The first thing to verify is the sync server's data path: the README's compose example mounts ./dnote_data at /data, and that directory holds the server's SQLite database, so an unbacked volume means an unrecoverable loss. The second is version compatibility between the CLI and server, given the separate versioning and the server 3.0.0 release. The third is the install script itself, which pipes a remote shell script directly into sh; download the release binary instead if that pattern is not acceptable in your environment. Everything else about Dnote is a local file you can inspect, copy, or delete, which is the strongest argument for it.
Editorial conclusion
Adopt Dnote if your notes are short, text-heavy, and you want them in a file you can copy, back up, or grep without a service account. Skip it if you need rich formatting, images, or multi-user collaboration, since nothing in the README or release notes suggests those exist. Before committing, verify two things on your own machine: that the install script from getdnote.com is acceptable to your security policy, and that the server binary's SQLite file lives on a volume you actually back up, because the compose example mounts ./dnote_data at /data and that directory is the entire server state.
Community notes