Rocketnotes: Markdown-Notizen mit LLM-Anbindung, lokal oder in der Cloud

Welche Lücke Rocketnotes für Notizbestände mit LLM-Bedarf schließt

Das Problem, das die README benennt, ist der Bruch zwischen Ablage und Auswertung. Notizen liegen als Markdown vor, die Fragen an sie stellt man aber in einem Chatfenster, und die Antwort stammt selten aus den eigenen Dateien. Rocketnotes setzt beides in dieselbe Oberfläche: einen Editor mit Syntaxhervorhebung, KaTeX und Mermaid, daneben einen Chat, der laut Beschreibung Antworten aus den eigenen Dokumenten zusammenstellt. Zielgruppe sind laut README ausdrücklich Entwickler und technische Nutzer, die Codeschnipsel sauber lesen und speichern wollen. Dazu kommen zwei Betriebsarten. Wer sich anmeldet, nutzt die gehostete Variante als Web- oder Electron-App; wer will, startet das Ganze laut INSTALLATION.md vollständig lokal über Docker und Ollama. Diese Zweiteilung ist die eigentliche Positionierung: derselbe Funktionsumfang, zwei sehr unterschiedliche Vertrauensmodelle für die eigenen Daten.

Wie Dokumente, Suche und Agent zusammenwirken

Der sichtbare Datenfluss beginnt in einem Baum aus Dokumenten mit beliebiger Verschachtelungstiefe, den die Oberfläche per Drag-and-drop umsortiert. Jedes Dokument lässt sich zusätzlich anpinnen, um es oben zu halten. Darüber liegen zwei Suchwege: eine Inhaltssuche über Schlüsselwörter und eine semantische Suche, die laut README die Bedeutung einer Anfrage auswertet statt nur Zeichenketten zu vergleichen. Technisch stützt sich das auf zwei verschiedene Vektorspeicher, S3 Vectors in der Cloud und ChromaDB im lokalen Betrieb, dazu sentence-transformers für die Einbettungen. Der Zettelkasten-Teil arbeitet anders: Schnipsel landen zuerst in einem Posteingang, ein Agent analysiert sie und fügt sie in das seiner Einschätzung nach passendste vorhandene Dokument ein. Das ist ein Schreibvorgang, kein Lesevorgang, und genau dort liegt das Risiko. Ein Agent, der selbst entscheidet, wohin ein Schnipsel gehört, verändert den Notizbestand. Die README zeigt den Ablauf in zwei Screenshots, beschreibt aber nicht, ob der Agent vor dem Einsortieren eine Bestätigung verlangt.

Installation: Docker-Pfad, Cloud-Pfad und was dazwischen liegt

Der lokale Weg ist in INSTALLATION.md unter dem Abschnitt zum Docker-Betrieb beschrieben; die README verlinkt dorthin, nennt aber selbst keine Befehle. Wer diesen Weg geht, muss zusätzlich Ollama betreiben, denn die Modelle laufen nicht im Container mit. Der Cloud-Weg ist ein Cognito-Login über takeniftynotes.auth.eu-central-1.amazoncognito.com mit einer fest verdrahteten Client-ID und der Weiterleitung auf app.takeniftynotes.net. Für eigene Deployments sind die GitHub-Workflows der Ankerpunkt: build-main.yaml, deploy.yaml, docker-build-and-publish.yaml und electron-build-and-publish.yaml. Wer den Dienst selbst hosten will, muss also aus diesen Workflows und dem Docker-Image rekonstruieren, welche Umgebungsvariablen und AWS-Ressourcen nötig sind. Der Stack gibt die Richtung vor: DynamoDB für die Datenbank, S3 für den Speicher, Cognito für die Anmeldung. Eine reine Container-Bereitstellung ohne AWS-Konto ist damit nicht beschrieben. Für den Entwicklungsbetrieb verweist die README auf CONTRIBUTING.md.

Modellwahl, MCP und Neovim als Anbindungspunkte

Die Multi-LLM-Unterstützung ist im README auf OpenAI, Anthropic und Together AI begrenzt. Das ist keine offene Abstraktion über beliebige Anbieter, sondern eine Aufzählung. Wer ein anderes Modell nutzen will, ist auf den lokalen Pfad mit Ollama angewiesen. Zwei Integrationspunkte fallen aus dem üblichen Funktionskatalog heraus. Erstens ein MCP-Server, der den eigenen Wissensbestand als Kontextquelle für andere LLM-Anwendungen bereitstellt. Zweitens ein Neovim-Plugin, das die Notizen in den Editor holt. Beide verschieben den Nutzen weg von der Web-Oberfläche: Der Bestand wird zur Ressource für Werkzeuge, die man ohnehin benutzt. Das ist der architektonisch interessanteste Teil, weil er die Frage aufwirft, wie viel Oberfläche ein Notiztool überhaupt braucht. Gleichzeitig bedeutet ein MCP-Server, dass der eigene Bestand über eine Schnittstelle nach außen erreichbar wird, und die README sagt nichts über Authentifizierung oder Zugriffsschutz an dieser Stelle.

Wo der lokale Modus an Grenzen stößt

Der lokale Betrieb ist der Grund, warum viele zu Rocketnotes greifen, und er ist zugleich die größte offene Fläche. Die vollständige Privatsphäre hängt daran, dass Einbettungsmodelle und Sprachmodell tatsächlich lokal laufen. Das Backend besteht laut Tech-Stack aus Go und Python, die AI-Schicht aus Langchain und Langgraph. Wer das selbst betreibt, wartet also auf eine Kette aus Container, Ollama und Modellgewichten. Die README macht keine Angaben zu Hardwareanforderungen, Modellgrößen oder Antwortzeiten, weder lokal noch in der Cloud. Das ist keine Kleinigkeit, sondern die zentrale Frage für jeden, der mit einem umfangreichen Notizbestand semantisch sucht. Ebenso unbeantwortet bleibt, wie die semantische Suche bei mehreren tausend Dokumenten skaliert und wann neu eingebettet wird. Für große Bestände sollte man das vor dem Umzug testen, nicht danach.

Abgrenzung zu Obsidian und Logseq

Die naheliegende Alternative ist Obsidian oder Logseq: reine Markdown-Editoren mit lokalem Dateibestand, bei denen die KI-Funktionen über Plugins nachgerüstet werden. Der Unterschied liegt nicht im Funktionsumfang, sondern im Datenmodell. Obsidian und Logseq behandeln das Dateisystem als Quelle der Wahrheit, jede Notiz bleibt eine Datei, die man mit git versionieren, per Skript durchsuchen und ohne das Tool öffnen kann. Rocketnotes speichert laut Tech-Stack in DynamoDB und S3. Selbst im Docker-Betrieb ist der Bestand damit ein Datenbankzustand, kein Verzeichnis. Das erkauft die agentische Archivierung, die semantische Suche und den MCP-Server, weil all das eine indexierte Ablage braucht. Es kostet die Selbstverständlichkeit, mit der man einen Notizbestand sonst kopiert, versioniert oder mit Kommandozeilenwerkzeugen bearbeitet. Wer den Bestand über Jahre als reine Dateisammlung erhalten will, ist hier falsch. Wer die Auswertung über die Ablage stellt, findet in Rocketnotes mehr eingebaut als in einem Obsidian-Grundgerüst.

Wartung, Release-Takt und Lizenz

Die Release-Historie zeigt ein unregelmäßiges Muster: v1.0.5 im Februar 2025, v1.0.6 im Juli 2025, v1.0.7 wenige Tage danach, der letzte Push ins Repository datiert auf April 2026. Daraus lässt sich kein Versprechen über Update-Kadenz ableiten, und die README nennt keine Stabilitätszusagen für die Cloud-API. Wer den Dienst selbst betreibt, trägt die Upgrade-Last für vier Komponenten gleichzeitig: die Angular- und Electron-Oberfläche, das Go-Backend, den Python-Teil mit Langchain und Langgraph sowie die Vektorspeicher. Langchain und Langgraph ändern ihre Schnittstellen vergleichsweise häufig, das ist ein bekannter Kostenfaktor in solchen Stacks. Zur Lizenz: Apache-2.0 erlaubt kommerzielle Nutzung und Modifikation und verlangt, dass Lizenz- und Urheberrechtshinweise erhalten bleiben; geänderte Dateien müssen gekennzeichnet werden. Wer Rocketnotes als gehosteten Dienst weiterverkauft, sollte die Namensrechte und die Markenhinweise im Repository prüfen. Das ist keine Rechtsberatung, sondern ein Hinweis auf die Stellen, die man vor einem kommerziellen Einsatz liest.

Redaktionelles Fazit

Rocketnotes passt zu einzelnen Nutzern und kleinen Gruppen, die Markdown als Ablageformat akzeptieren und den lokalen Docker-Pfad mit Ollama tatsächlich aufsetzen wollen, statt nur die Cloud-Variante zu abonnieren. Wer eine rein lokale Installation ohne Modell-Downloads oder ohne Container erwartet, wird enttäuscht; ebenso wenig ist das Projekt ein Mehrbenutzer-Wiki mit Rechteverwaltung. Vor dem Umzug eigener Notizen sollte man INSTALLATION.md und die Docker-Umgebungsvariablen prüfen, einen Export der bestehenden Markdown-Dateien testen und erst danach entscheiden, ob die agentische Archivierung in den eigenen Ablauf passt.

Offizielle Quellen

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