Rocketnotes: a Markdown editor where the AI runs on your own machine

What Rocketnotes does that a plain Markdown folder does not

A folder of .md files is excellent at storage and terrible at retrieval. Once you pass a few hundred notes, you remember that you wrote something about a topic but not the words you used, so keyword search returns nothing. Rocketnotes attacks that gap directly. The README lists content search and semantic search as separate features, which is the honest framing: one is substring matching, the other is embedding similarity, and they fail in different ways.

The second gap is filing. Anyone who keeps a Zettelkasten knows the inbox problem: capture is fast, sorting is slow, so snippets pile up. Rocketnotes ships a Zettelkasten inbox where you type or dictate a snippet, and an AI agent then inserts it into the most relevant existing document. That is a real workflow decision, not a chat window bolted onto an editor.

Who it is for: developers and technical writers who already keep notes in Markdown and want LLM features without sending the corpus to someone else's endpoint. The README targets that reader explicitly with code syntax highlighting, Katex and Mermaid support, and a Neovim plugin. If you live in a code editor and want your notes to follow you there, the feature list is aimed at you.

How the pieces fit: Angular, Go, Python and an embedding store

The repository layout makes the architecture legible without reading source. There are two Go Lambda handlers, handler-crud and handler-ai, an mcp/ directory, a webapp/ directory, a cdk/ directory for infrastructure, and a template.yaml for AWS SAM. The README's tech stack section states the split: Angular, TypeScript and Electron on the front, Go and Python on the back, DynamoDB for the database and S3 for storage.

The AI layer is where the two deployment modes diverge. In the cloud, the README names S3 Vectors as the vector store. Locally, docker-compose.yaml runs a chroma service from the chromadb/chroma image, and the s3 service is adobe/s3mock started with initialBuckets=faissIndexBucket. So the same application code talks to an S3-compatible API either way, and only the vector backend changes. That is a clean seam and it explains why the local stack needs an S3 mock at all rather than just a database.

Embeddings come from sentence-transformers in the local mode, and Ollama serves the models. The README lists Ollama among the built technologies and the compose file defines an ollama service on port 11434. For hosted usage, the README says the app supports OpenAI, Anthropic and Together AI models, and the topics list adds Hugging Face and LangChain. LangGraph appears in the stack, which matches the agentic archiving feature: filing a snippet into the right document is a multi-step decision, not a single completion.

Installing Rocketnotes with Docker and taking a first note

The README points at two paths. You can sign up for the hosted app and use it as a web or Electron client, or you can run it 100% locally with Docker, and for that it links INSTALLATION.md with the anchor run-with-docker. The repository also documents a development setup in CONTRIBUTING.md. The commands below come from the root package.json scripts and docker-compose.yaml, so they describe the development route rather than the published install guide.

Start the backing services. The start-services script brings up dynamodb, s3 and chroma as detached containers, which is the minimum needed before the API can do anything useful.

npm run start-services

Initialize the local database. The init-db script runs dynamodb-init.sh, which creates the tables the CRUD handler expects against the local DynamoDB instance.

npm run init-db

Build and start the API. build-api runs sam build, and start-api runs the SAM local API on the Docker network named in the compose file, with warm containers so the first request is not a cold start.

npm run build-api
npm run start-api

Finally, start the webapp. The script changes into webapp/ and runs the Angular dev server.

npm run start-webapp

The compose file publishes the webapp on port 3001 and passes API_URL: "http://localhost:3002", so the front end expects the API on 3002, which is the port start-api uses. The API container carries a mem_limit of 8g and mounts the Docker socket, because SAM local starts Lambda containers underneath. Expect a heavy first run: the compose file pulls fynnfluegge/rocketnotes-api and fynnfluegge/rocketnotes-webapp images plus Ollama, and the ollama service is set to pull_policy: always. Once the editor loads, create a document in the tree, then open the Zettelkasten inbox and save a snippet. According to the README, the agent will file that snippet into the most relevant document rather than leaving it in the inbox.

The local mode is a stack, not a switch

The phrase 100% local is accurate but load-bearing. It describes a deployment where Ollama answers the model calls and ChromaDB holds the embeddings, and the README presents it as a Docker mode rather than a setting inside the hosted app. There is no documented toggle that turns an existing hosted account into a local one. If your reason for choosing Rocketnotes is data residency, you are choosing the Docker path and everything it implies.

That path has real weight. The stack is DynamoDB local, an S3 mock, ChromaDB, Ollama, the SAM API container and the webapp container: six services before you have written a note. The API container is limited to 8 GB of memory and needs the host Docker socket. The compose file pins platform: linux/amd64 for the API and webapp images, so on an ARM machine you are running under emulation. The README's own feature list mentions a Neovim plugin and an MCP server, but it does not document rollback, backup, or export of the DynamoDB and S3 contents. Notes stored in a database and an object store are not the same as notes in a directory, and nothing in the repository documentation describes getting them back out.

There is also a licence discrepancy worth noticing. The repository LICENSE is Apache-2.0 and the README badge says Apache 2.0, but the root package.json carries "license": "MIT". For a self-hosted personal tool this is unlikely to matter, but anyone redistributing a modified build should read the actual LICENSE file rather than either metadata field.

Rocketnotes against Obsidian, Logseq and plain Neovim

The obvious comparison is Obsidian or Logseq. Those tools keep your vault as files on disk and treat plugins as the extension point; AI features arrive through community plugins that call whichever API you configure. Rocketnotes inverts both choices. Notes live in DynamoDB with content in S3, and AI is a first-class part of the application rather than a plugin, with chat, completion, transcription and agentic archiving shipped in the core. The practical difference shows up when something breaks: with a vault you can open the file in any editor, while with Rocketnotes you are debugging a six-service stack.

Against a plain Neovim plus an LLM plugin, the trade is reversed again. Neovim gives you speed and a single process, and Rocketnotes gives you a document tree, semantic search, sharing and a filing agent. The project ships a Neovim plugin, which reads as an acknowledgement that some users want both rather than a replacement.

The closest conceptual alternative is a static-site or wiki tool with a retrieval layer bolted on. The distinction is the agentic archiving loop. Most note tools with embeddings give you search; Rocketnotes also proposes a destination for the captured snippet. Whether an LLM should decide where your notes live is a judgement call, and the README does not describe an undo for a misfiled snippet.

Maintenance, upgrades and what the release history shows

The repository is not archived, and the last push was on 2026-04-23. Releases are modest and spaced out: v1.0.5 in February 2025, v1.0.6 in July 2025, v1.0.7 later the same month. The root package.json still reads version 1.0.3, so the version number in that file is not the release you are running. Anyone tracking the project should watch the release tags rather than the manifest.

Upgrade cost depends on which mode you run. In the hosted mode, upgrades are someone else's problem. In the Docker mode, the compose file references floating tags: fynnfluegge/rocketnotes-api:latest and fynnfluegge/rocketnotes-webapp:latest, plus ollama/ollama:latest with pull_policy: always. ChromaDB is the exception, pinned at chromadb/chroma:0.4.24. That mix means a restart can change your API and webapp without warning while the vector store stays fixed, which is the configuration most likely to produce a version mismatch. If you self-host, pin the API and webapp tags to a release you have tested.

The Go module declares go 1.23.0 with toolchain go1.24.1, and the CDK dependencies sit on v2.193.0 while several alpha constructs remain at v2.114.1-alpha.0. Alpha CDK constructs change between minor versions, so a rebuild of the infrastructure after a dependency bump is more likely to need attention than the application code. On licensing, Apache-2.0 permits commercial use and modification and includes an explicit patent grant; the MIT declaration in package.json is inconsistent with the LICENSE file, and that is a question for the maintainer rather than something to resolve by assumption.

Editorial conclusion

Adopt Rocketnotes if you want an AI-assisted Markdown base you can host yourself and you are comfortable running a multi-container stack with Ollama, since that is the only route the documentation gives to 100% local processing. Do not adopt it if you want a single binary, a mobile client, or a tool that syncs notes through a plain Git remote; the README describes a web and Electron app backed by DynamoDB and S3-compatible storage, not a folder of files you can rsync. Before committing, run the docker-compose services and confirm that the webapp container on port 3001 reaches the API on port 3002, and check the Apache-2.0 LICENSE file against the MIT field in package.json.

Frequently asked questions

Official sources

1. fynnfluegge/rocketnotes on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases