Dnote: a command line notebook that keeps your notes in one SQLite file

What Dnote actually replaces

Most note tools ask you to accept a database you cannot open, a web editor you cannot script, or a subscription that gates sync. Dnote takes the opposite position: the README describes it as a "simple command line notebook" with a single binary and no dependencies, and states that notes live in one SQLite file. That file is the product. You can copy it, grep it with sqlite3, put it in a backup job, or delete it without asking anyone.

The target user is someone who already lives in a terminal and wants capture to cost one command. The README's first example is `dnote add linux -c "Check disk usage with df -h"`, which shows the intended shape: a book name, an optional inline note, and no editor window. Omit the `-c` flag and Dnote opens your editor instead, so the same command covers quick capture and longer writing.

It has existed since 2017 according to the README, and the repository is still receiving commits: the last push was on 2026-07-25. It is not archived. That matters less than it sounds, because the storage format is SQLite and the CLI is a Go binary, so the exit cost is low either way.

Books, notes and the sync server

The data model is two levels: books and notes. A book is a named collection, and the README's example uses `linux` as the book for a shell tip. There is no folder hierarchy, no tagging system mentioned in the README, and no cross-book links. If your notes need a graph, this is the wrong shape.

The CLI side is deliberately thin. `dnote add` writes, `dnote view` lists a book, `dnote find` runs a full-text search, and `dnote sync` talks to a server. Each of those appears in the README's opening code sample, which is the whole command surface a new user needs to start.

The server is where the architecture gets interesting. The README says the server is "a binary with SQLite embedded" and that no database setup is required, so the sync endpoint carries the same storage assumption as the client. The Go module list confirms this: `gorm.io/driver/sqlite` and `github.com/mattn/go-sqlite3` are direct dependencies, alongside `gorilla/mux` for routing, `gorilla/csrf` for request protection, and `golang.org/x/crypto`. Sync is therefore not a distributed database. It is a single-writer SQLite service behind a REST API. The README mentions REST API access as a feature, which means you can script against the server directly rather than only through the CLI.

That design has a consequence the README does not spell out. Two devices syncing through one server are serialising writes through one SQLite file, and the repository does not document conflict resolution behaviour. The release notes for server-v3.0.0 and cli-v0.16.0 are not reproduced in the README, so anything about merge strategy would be guesswork.

Installing Dnote and taking a first note

The README gives two install paths. The shell installer covers Linux, macOS, FreeBSD and Windows, and Homebrew covers macOS. Both are one line.

curl -s https://www.getdnote.com/install | sh

After that, Homebrew users on macOS have a second option:

brew install dnote

The README also points to the GitHub releases page for a direct binary download if you would rather not pipe a script into a shell, which is a reasonable instinct on a shared machine.

Once the binary is on your PATH, the first real use is adding a note to a book. The README's own example is a shell tip:

dnote add linux -c "Check disk usage with df -h"

Leaving off `-c` opens your editor, which is how you would write anything longer than a line. To see what landed, view the book:

dnote view linux

And to find something you half remember, search across notes:

dnote find "disk usage"

If you want the same notes on a second machine, the README's Docker path is a compose file with the image `dnote/dnote:latest`, the container name `dnote`, port `3001:3001`, a volume mapping `./dnote_data:/data`, and `restart: unless-stopped`. Bring it up with `docker-compose up -d`, then run `dnote sync` on each client. The README also links a guide for binary installation of the server, and the repository root contains a SELF_HOSTING.md file for the same purpose.

Where Dnote stops being the right tool

The obvious limitation is the interface. There is a server component, and the Go module list includes `gopkg.in/gomail.v2` for email and a `pkg/server/assets` directory that the Makefile builds with npm, so the server does ship a web surface. But the README documents the product as a command line notebook and does not describe a mobile client, a desktop app or a browser extension. If your capture habit is on a phone, Dnote does not meet you there.

The second limitation is self-hosting. Sync is not a service you sign up for; it is a binary or container you run. That means TLS termination, backups of the `/data` volume, and an upgrade path are your responsibility. The README's compose file publishes port 3001 and mounts a relative `./dnote_data` directory, which is fine for a home server and insufficient for anything exposed to the internet without a reverse proxy in front.

The third is search scope. `dnote find` is described as full-text search, and the storage is SQLite, but the README does not describe ranking, stemming or fuzzy matching. Treat it as a substring-and-index lookup over your own notes, not as a retrieval system. If you need semantic search across thousands of documents, SQLite FTS is a floor, not a ceiling, and you would be building on top of the file rather than using Dnote's own commands.

Finally, the book model has no nesting. A user with hundreds of notes across overlapping subjects will end up with a flat list of book names and no way to reorganise them except by editing notes one at a time.

Dnote against a plain text file and against a wiki

The honest alternative for many people is a directory of Markdown files plus ripgrep. That approach gives you the same portability, better editor integration, and a format every tool on earth can read. What it does not give you is a write path with a name for each collection, an incremental sync protocol, or a server that other devices can pull from. Dnote's value is that `dnote add linux -c "..."` is faster to type than opening a file and deciding where it goes, and that `dnote sync` moves the result without you configuring a remote.

The other alternative is a self-hosted wiki such as a Markdown-backed knowledge base with a web editor. Those give you a browser, backlinks and a mobile-friendly view, at the cost of a heavier stack and a database you did not choose. Dnote's counter-argument is stated plainly in its README: one SQLite file, portable and searchable. If you never open that file, you are paying the CLI's constraints without collecting its benefit.

A middle path worth naming: use Dnote for capture and keep a separate export step. The README does not document an export command, so verify that yourself before assuming the SQLite file is easy to convert into your other tool's format.

Maintenance, licensing and the upgrade bill

Dnote is licensed under Apache-2.0, which permits commercial use, modification and redistribution provided you keep the licence and notice files and state significant changes. That is a permissive licence with an explicit patent grant, and it is the least complicated part of adopting the project. Nothing in the README suggests a dual-licence model or a hosted tier that changes the terms; the homepage is a documentation and download site.

Maintenance cost is where you should think hardest. The repository is not archived and the last push was on 2026-07-25, with the most recent CLI release cli-v0.16.0 dated 2025-11-08 and the server release server-v3.0.0 dated 2025-11-01. Those are the only release facts available, and they suggest a project that ships occasionally rather than continuously. The CLI and the server are versioned separately, which is a real operational detail: you can upgrade one without the other, and you should check compatibility rather than assuming the latest of each belongs together.

The build itself is not trivial if you compile from source. The Makefile requires Go and npm, downloads Go modules, and runs npm install inside `pkg/server/assets`. There are separate test targets for CLI, API and end-to-end suites, and the server build requires a `version` argument. For most users the prebuilt binary and the `dnote/dnote:latest` image avoid all of this. If you plan to patch Dnote, budget for a two-language toolchain.

Editorial conclusion

Adopt Dnote if you want a small CLI notebook whose entire state is one SQLite file and you are prepared to run the sync server yourself when you need more than one machine. Skip it if you expect a graphical editor, mobile clients or a hosted service to appear in the box; the repository ships a CLI and a server, nothing else. Before committing, install the binary, run dnote add and dnote find against a throwaway database, and read SELF_HOSTING.md to confirm the Docker compose file and the ./dnote_data volume mapping match your host.

Frequently asked questions

Official sources

1. dnote/dnote on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases