Rocketnotes: a Markdown editor that runs its own LLM retrieval stack
✨ AI-powered markdown editor - leverage LLMs with your documents - 100% local or in the cloud
At a glance
- What is it?
- Rocketnotes pairs a hierarchical Markdown editor with LangChain and LangGraph agents, and can run entirely on your machine through Docker and Ollama. The interesting part is the agentic archiving inbox; the parts to verify first are the local install and the cloud dependency split.
- Who is it for?
- Adopt Rocketnotes if you want your Markdown notes and your retrieval layer in the same repository, and if you are willing to run the Docker and Ollama path so that document text never leaves the machine. Do not adopt it if you need a sync protocol that works across arbitrary third-party editors, or if you expect a hosted account to give you the same feature surface as the self-hosted stack.
- 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 146 days ago.
- What is it written in?
- Mainly TypeScript, 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 Rocketnotes picks, and who it is actually for
Markdown notes are portable. The retrieval layer around them usually is not. Once you want semantic search, chat over your own documents, or an agent that files new snippets into the right note, you end up bolting a vector database and an embedding pipeline onto a folder of .md files, and that glue is where the project dies. Rocketnotes puts the editor and the AI pipeline in one application so the index and the documents move together. The README describes it as a web-based Markdown note taking app with native AI feature integrations, built on langchain, langgraph, S3 Vectors, ChromaDB, sentence-transformers and Ollama. The audience is narrow and identifiable: people who already keep notes in Markdown, want code blocks, KaTeX and Mermaid inside those notes, and are willing to run a Docker stack or sign up for a hosted account rather than install a plugin into an editor they already use. If your notes live in Obsidian and you only want a chat sidebar, this is a larger commitment than the problem requires. The project also ships a Neovim plugin, which suggests the author expects at least some users to keep editing outside the web app and treat Rocketnotes as the storage and retrieval backend.
What the AI layer is made of, and where the vectors live
The README names the components but not the wiring, so treat the following as the architecture the repository advertises rather than a verified data flow. LangChain sits under the model calls, LangGraph under the agent workflows, and the vector store differs by mode: S3 Vectors for the cloud deployment and ChromaDB for the local one. Embeddings come from sentence-transformers, and Ollama is the local model runtime. That split is the most consequential design decision in the project. It means the local Docker mode and the hosted account are not the same system with a different URL; they use different vector backends, which in turn implies different index behaviour, different persistence, and different failure modes. The README lists multi-LLM support for OpenAI, Anthropic and Together AI models, and the topics list adds Hugging Face, AWS and serverless. Cloud mode leans on DynamoDB for the database and S3 for storage, per the tech stack section. The backend is described as Go plus Python, which fits the pattern: a Go service for the document API and a Python service for the LangChain and LangGraph work. The frontend is Angular and TypeScript, wrapped by Electron for the desktop build. Nothing in the supplied material states how embeddings are chunked, how re-indexing is triggered when a document changes, or what happens to the index when a document is deleted. Those are the first questions to answer before trusting the semantic search with a large vault.
Getting it running: two paths, one of them documented
The README offers three entry points. The hosted route is a Cognito sign-up link that leads to app.takeniftynotes.net, usable as a web app or as an Electron app. The self-hosted route is a link to INSTALLATION.md with the anchor run-with-docker, and the README states that this runs the application 100% locally with Ollama for what it calls 100% local and private AI processing. The third route is the contribution guide, which the README points to as the way to set up a local dev environment. The supplied material does not include the contents of INSTALLATION.md, so the exact Docker commands, image names, environment variables and Ollama model tags are not something I can quote. What can be said from the repository layout is that Docker images are published by a dedicated GitHub Actions workflow, docker-build-and-publish.yaml, and that a separate electron-build-and-publish.yaml handles the desktop artifacts, with build-main.yaml and deploy.yaml covering the build and deploy paths. If you are evaluating this for a team, the practical check is whether INSTALLATION.md pins a model tag and a ChromaDB configuration or leaves both to defaults; a local mode that silently falls back to a remote embedding endpoint would defeat the stated privacy property, and the README does not say which way it goes.
The Zettelkasten inbox is the feature worth judging the project on
Most of the feature list is table stakes for a modern notes app: syntax highlighting, a hierarchical tree with drag and drop, content search, document sharing. The one item that is not table stakes is the Zettelkasten inbox with agentic archiving. The README describes it as an AI agent that analyzes snippets from your inbox and files them into the most relevant existing document, and the screenshots show a two-step flow where you capture a snippet by typing or voice recording and then let the agent insert it into the right place. This is a genuinely harder problem than chat, because the agent has to make a write decision rather than a read one. A wrong chat answer costs you a re-ask. A wrong archive costs you a note you cannot find later, in a system whose whole premise is that filing is automatic. The README does not describe a confirmation step, an undo path, or a confidence threshold, and it does not say whether the agent can create a new document when no existing one fits. Until that is documented, the honest position is that agentic archiving is the feature most likely to need manual review, and the one to trial on a throwaway vault before pointing it at years of notes. The Neovim plugin and the MCP server integration are the two features that make the knowledge base reachable from tools other than the web editor, and the MCP server in particular is the reason to care about the retrieval quality: whatever the agent retrieves is what any connected LLM application will see.
Where it is the wrong tool
Rocketnotes is not a sync layer. The README describes document sharing and a hierarchical tree, but nothing about conflict resolution, offline editing, or a file format that other editors can round-trip without loss. If your requirement is that the same folder of Markdown files stays editable in whatever editor each person prefers, with a separate index that can be rebuilt from scratch, Rocketnotes inverts that: the application owns the documents, and the AI features depend on the application's own storage. That is a reasonable trade for a single user or a small team standardising on one tool, and a poor one for anyone whose notes outlive the tool. The second limitation is the mode split. Local Docker mode is the privacy story, but the README does not state that every feature works identically there. Semantic search and chat depend on embeddings, and the local path uses ChromaDB with sentence-transformers while the cloud path uses S3 Vectors; voice-to-text transcription is listed as a feature without any statement about which engine performs it or whether it runs locally. Multi-LLM support names OpenAI, Anthropic and Together AI, which are remote providers, alongside Ollama for local models. A user who picks the Docker route expecting no network calls should confirm that the transcription and embedding paths are also local, because the README does not make that claim explicitly.
How it compares to wiring an AI plugin into an editor you already use
The obvious alternative is to keep your existing editor and add an AI extension plus a separate vector store, which is the pattern most Markdown users already run. The difference in approach is not the model. It is who owns the index. With an editor plugin, the Markdown files remain the source of truth and the index is a derived artifact you can delete and rebuild at will; you accept that the plugin sees only what the editor exposes, and that chat quality depends on whatever indexing the plugin does. Rocketnotes takes the opposite position: the application is the system of record, the document tree, the vector store and the agent workflows are one product, and the integration surface for outside tools is the MCP server and the Neovim plugin rather than a folder. That buys tighter retrieval, because the app controls chunking and metadata, and it costs you portability. The second alternative is a plain Zettelkasten workflow with manual filing and keyword search. Rocketnotes' agentic archiving is a direct attempt to remove that manual step, and the comparison is honest only if the agent's filing decisions are good enough that you stop double-checking them. Nothing in the supplied material lets me claim they are.
Maintenance, releases and the Apache-2.0 terms
The release history in the supplied material shows v1.0.5 in February 2025, v1.0.6 in July 2025, v1.0.7 later the same month, and a last push in April 2026. That is a project with infrequent but real releases, and a gap between the last tagged release and the last commit that is worth noting if you plan to track main rather than tags. The four GitHub Actions workflows (build-main, deploy, docker-build-and-publish, electron-build-and-publish) mean the project ships its own Docker and Electron artifacts, so self-hosters are not required to build from source, but the desktop and container builds are separate pipelines and can drift. Rocketnotes is Apache-2.0, which permits commercial use, modification and redistribution provided the licence and notices are preserved and any modified files carry prominent change notices; it also includes an explicit patent grant. That is a permissive licence, not a copyleft one, so embedding Rocketnotes in an internal tool raises no source-disclosure obligation. This is a description of the licence text, not legal advice, and the usual caveat applies: if you redistribute a modified build, read the NOTICE and attribution requirements yourself. The maintenance cost that actually matters here is the model side. A self-hosted deployment depends on Ollama and on sentence-transformers for embeddings, and both move independently of Rocketnotes; a pinned model tag in your deployment is the difference between a reproducible setup and one that changes behaviour after an unrelated upgrade.
Editorial conclusion
Adopt Rocketnotes if you want your Markdown notes and your retrieval layer in the same repository, and if you are willing to run the Docker and Ollama path so that document text never leaves the machine. Do not adopt it if you need a sync protocol that works across arbitrary third-party editors, or if you expect a hosted account to give you the same feature surface as the self-hosted stack. Before committing, verify three things in order: that the Docker install in INSTALLATION.md completes on your hardware, that your chosen local model is actually pulled and reachable by Ollama, and that the S3 Vectors versus ChromaDB vector store split matches the mode you intend to run.
Community notes