KnowNote
EN中文
Source code

1.3.0GPL-3.0

Install

14 September 2026

What a Docker-free desktop app costs

Not shipping a container removes a real barrier, and it removes a lot of other things too. An honest accounting of what this project gives up.

The reason KnowNote is a desktop application rather than a self-hosted stack is narrow and specific: the people this tool is for were never going to run docker compose up. For a student with a laptop and a folder of lecture PDFs, “just spin up the stack” is a full stop. Removing that step is the entire value proposition for that person.

The cost of that decision is real, and it is worth writing down, because a project that only advertises the upside of its architecture is not telling you how to evaluate it.

You ship a binary, so you own code signing

A hosted service or a container image has no installer. A desktop app has one, and an installer that is not code-signed produces a scary prompt:

  • macOS quarantines the app and reports it as damaged.
  • Windows SmartScreen blocks the installer behind a “More info” link.

The workarounds are one line of xattr or one click, and they are documented. But an Apple Developer ID costs money every year, and the release pipeline has no certificate, so the correct answer for now is to explain the prompt rather than pretend it does not exist.

You own cross-platform packaging

A container image is one artifact. A desktop app is one per platform and per architecture, and the native modules in the stack have to be rebuilt for the target — the SQLite binding and the ONNX runtime are not portable blobs.

The practical consequence here: releases are built for macOS on Apple Silicon and Windows on x64, and nothing else. There is no Linux build, and no Intel Mac build, because the release matrix is run by one person and each addition is another runner, another set of native builds and another thing that can break on a Friday.

You cannot multi-user your way out of a design problem

A server can be shared. It has accounts, sessions and a permission model, and once those exist, any awkward local-state question can be answered with “put it in the database”.

A desktop app has none of that scaffolding. Every piece of state belongs to one person on one machine, and there is no server to arbitrate. For this tool that is a feature — there is no account to create and nothing to sign in to — but it also means there is no path to ever making it collaborative without becoming a different product.

There is no “we”

The largest cost is not technical. A hosted product has an organisation behind it: someone to answer support, someone to notice a broken release, someone whose job continues. This project has one maintainer, and the honest comparison has to say so. If you need something dependable for work tomorrow, that difference should weigh more than any argument on this website.

What is bought with all that

For the person the tool was built for:

  • no deployment, no container, no server to keep running;
  • nothing to sign up for, and no document that leaves the machine to be embedded;
  • a library that is a file on disk, which they can back up, move and delete;
  • retrieval that works with the network off.

That is a good trade for one specific person and a bad trade for a team. Deciding which one you are is the actual comparison, and it is not a comparison any feature table can make for you.