OpenDAN: ein Personal AI OS als Docker-Container mit Agenten, Wissensbasis und Workflows
OpenDAN is an open source Personal AI OS , which consolidates various AI modules in one place for your personal use.
Auf einen Blick
- Was ist das?
- OpenDAN bündelt Agenten, lokale Wissensbasis und Workflow-Ketten in einem Container. Das Projekt bezeichnet sich selbst als früh, die MVP-Version 0.5.1 trägt diesen Hinweis zu Recht.
- Für wen ist es gedacht?
- Wer einen einzelnen Rechner besitzt, Docker ohnehin laufen hat und ausprobieren will, wie ein Agent auf lokale Dateien und E-Mails zugreift, kann OpenDAN 0.5.1 installieren und die Wissensbasis gegen das eigene Datenverzeichnis testen. Wer produktive Termin- oder Korrespondenzverwaltung braucht, sollte zuerst prüfen, ob der Telegram- und E-Mail-Anbindung in der eigenen Umgebung vertraut werden kann, und ob die Wissensbasis tatsächlich alle benötigten Dateiformate liest.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 171 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem OpenDAN adressiert und für wen es gedacht ist
Die Ausgangslage, die das Repository beschreibt, ist die Zersplitterung: Wer heute einen Assistenten, einen Übersetzer, eine Wissensablage und einen Werkzeugaufruf für die Kommandozeile nutzen will, richtet vier Dienste mit vier Datenhaltungen ein. OpenDAN setzt dagegen auf einen einzigen Container, in dem die Module nebeneinander laufen und sich dieselben lokalen Daten teilen. Die README nennt als Zielgruppe ausdrücklich Privatpersonen, die Agenten wie Butler, Assistenten, Nachhilfelehrer oder digitale Begleiter selbst zusammenstellen und die Kontrolle behalten wollen. Der Anspruch reicht bis zu Smart-Home-Geräten und bestehenden Diensten.
Für Entwickler ist der zweite Installationsweg relevant. Die README schreibt, die Installation aus dem Quellcode sei "necessary", wenn man OpenDAN weiterentwickeln will, und warnt gleichzeitig vor "traditional Python dependence problems". Das ist eine ehrliche Formulierung: Der Docker-Weg ist der empfohlene, der Quellcode-Weg der für Mitwirkende. Wer nur Anwender ist, hat mit dem Container weniger Reibung.
Agenten, Wissensbasis, Workflows: die Bausteine im Container
Die README unterscheidet drei Konzepte. Ein AI Agent wird von einem großen Sprachmodell angetrieben; die MVP-Version bringt vier mit. Jarvis verwaltet Termine und Kommunikationsverläufe und wird als ChatGPT-Alternative beschrieben. Mia verwaltet persönliche Daten und sortiert sie in eine Wissensbasis. Tracy ist als Englischlehrerin angelegt. ai_bash richtet sich an Entwickler und übersetzt natürlichsprachliche Anweisungen wie "Find FILES in ~/Documents that Contain OpenDAN" in Kommandozeilenaufrufe.
Die Wissensbasis entsteht laut README aus "existing file or email spiders", also aus Sammlern, die vorhandene Dateien oder Postfächer durchsuchen. Unterstützt werden Textdateien und gängige Bildformate; weitere Formate sind in der Liste offen. Damit ist der Datenfluss klar: Dateien bleiben auf der lokalen Platte, ein Spider liest sie ein, der Agent greift über die Wissensbasis darauf zu. Für E-Mails gilt dasselbe Muster, was bedeutet, dass Zugangsdaten für ein Postfach im Spiel sind.
Workflows verbinden mehrere Agenten. Das einzige im README genannte Beispiel ist story_maker, das AIGC-Werkzeuge einbindet und daraus ein Hörbuch mit Märchen erzeugt. Zusätzlich nennt das Projekt einen "Distributed AI computing core", der für aufwendigere Auswahlschritte zur Verfügung steht. Details dazu bleiben im Material dünn; die README beschreibt weder Verteilungsprotokoll noch Fehlerverhalten.
Installation über Docker: die konkreten Befehle
Der Ablauf ist kurz. Zuerst prüft man die Docker-Version; die README erwartet eine Nummer über 20.0:
docker -version
Dann wird das Image geholt:
docker pull paios/aios:latest
Der erste Start braucht ein Terminal, weil eine Initialisierung mit Eingaben läuft. Deshalb gehört das Flag -it dazu, und ein lokales Verzeichnis wird als Volume eingehängt, damit die entstehenden persönlichen Daten auf der eigenen Platte liegen:
docker run -v /your/local/myai/:/root/myai --name aios -it paios/aios:latest
Spätere Starts erfolgen mit docker start -ai aios. Soll der Dienst ohne Oberfläche laufen, lässt man das -ai weg und verwendet docker start aios. Nach der Konfiguration landet man in einer Shell, die die README mit einer Linux-Bash vergleicht und in der man mit dem Agenten Jarvis spricht.
Ein Punkt, den man vorher klären muss: Für den Betrieb wird ein OpenAI-API-Token verlangt. Die README räumt ein, dass die Beantragung für Neueinsteiger Hürden haben kann, und verweist auf temporäre Tokens aus einer Testgruppe mit begrenztem Verbrauch und begrenzter Laufzeit. Für den lokalen Betrieb nennt die Feature-Liste zusätzlich das offene Modell LLaMa als umschaltbare Option. Ob der Wechsel ohne Token vollständig funktioniert, lässt sich aus dem Material nicht belegen.
Wo OpenDAN an Grenzen stößt
Die deutlichste Einschränkung steht im Repository selbst: Das Projekt sei "still in its very early stages", und es könne "significant changes" geben. Wer auf Stabilität angewiesen ist, plant hier gegen eine bewegliche Fläche. Die Versionsgeschichte stützt das. Auf 0.0.3 und 0.0.4 im Juni 2023 folgte erst im April 2024 die MVP-Version 0.5.1, danach listet das Repository keinen weiteren Release. Der letzte Push liegt später, aber ein Release ist kein Commit.
Die Wissensbasis ist der zweite wunde Punkt. Text und gängige Bildformate sind abgehakt, andere Formate nicht. Für einen Haushalt, in dem PDFs, Tabellen und Präsentationen liegen, heißt das: Ein Teil der Dokumente bleibt für Mia unsichtbar. Die README benennt das offen als offenen Punkt.
Der dritte Punkt ist der Betriebsmodus. Die MVP-Version läuft laut README im "all-in-one"-Modus. Der eigentliche OS-Kernel soll erst in 0.5.2 auf Basis bereits fertiger Teile des CYFS Owner Online Device OS entstehen. Bis dahin ist OpenDAN eher ein Bündel von Diensten in einem Container als ein Betriebssystem im engeren Sinn. Wer Prozessisolation, Rechteverwaltung oder Ressourcenlimits zwischen Agenten erwartet, findet dafür im Material keinen Beleg.
Abgrenzung zu einem reinen Chat-Frontend
Der naheliegende Vergleich ist ein lokales Chat-Interface, das ein Modell lädt und Fragen beantwortet. Der Unterschied liegt weniger im Modell als in der Umgebung: OpenDAN bringt eine Wissensbasis mit, die aus Dateien und E-Mails gespeist wird, und es bringt Werkzeugaufrufe mit, etwa ai_bash. Ein Chat-Frontend beantwortet eine Frage; OpenDAN soll eine Datei finden oder einen Termin ablegen.
Der Preis dafür ist Konfigurationsaufwand. Ein Chat-Frontend braucht ein Modell und einen Port. OpenDAN braucht Docker, ein Volume für /root/myai, einen API-Token, je nach Nutzung Zugangsdaten für Telegram oder E-Mail sowie die Entscheidung, welche Verzeichnisse überhaupt eingelesen werden. Wer nur gelegentlich ein Modell befragen will, bezahlt diesen Aufwand ohne Gegenwert. Umgekehrt gilt: Wer Dateien durchsuchen und Aktionen auslösen will, kommt mit einem Chat-Frontend nicht weit.
Wartung, Upgrades und die MIT-Lizenz
Upgrades laufen über das Image. Die README verwendet den Tag latest, was bedeutet, dass ein docker pull paios/aios:latest jederzeit eine andere Version ziehen kann als die, mit der man gestartet ist. Wer reproduzierbare Zustände braucht, sollte stattdessen den Versions-Tag verwenden, sofern einer verfügbar ist. Die persönlichen Daten liegen im eingehängten Verzeichnis und überleben einen Containerwechsel, sofern das Volume bleibt.
Das Projekt hat sich selbst einen Zeitplan gesetzt: Der OpenDAN Store für Agenten, Workflows und Modelle war für 0.5.1 geplant und wurde auf 0.5.2 verschoben. Bis dahin erfolgt die Installation neuer Agenten und Workflows laut README manuell. Das ist der eigentliche Wartungsposten: Jede Erweiterung ist Handarbeit, und nach einem Image-Update ist unklar, ob manuell installierte Bestandteile weiter funktionieren.
Die Lizenz ist MIT. Das erlaubt kommerzielle Nutzung, Veränderung und Weitergabe, solange Lizenztext und Urheberrechtshinweis beiliegen. Für eingebundene Modelle und AIGC-Werkzeuge gilt die MIT-Lizenz des Projekts nicht automatisch; deren Bedingungen muss man getrennt prüfen. Das ist keine Rechtsberatung, sondern der Hinweis, dass die Lizenzangabe im Repository nur den Code von OpenDAN selbst abdeckt.
Für wen sich der Einstieg lohnt und was zuerst zu prüfen ist
OpenDAN ist dann interessant, wenn mehrere Bedingungen gleichzeitig erfüllt sind: ein Rechner, auf dem Docker ohnehin läuft, privates Material, das man einem lokalen Agenten zugänglich machen will, und die Bereitschaft, mit einer Version zu arbeiten, die sich noch bewegt. Die Hardwareliste in der README reicht von PC über Mac und Raspberry Pi bis NAS. Der Container ist damit breit einsetzbar.
Vor dem ersten docker run sollte man drei Dinge klären. Erstens, ob ein OpenAI-Token beschafft werden kann oder ob der lokale LLaMa-Pfad tatsächlich trägt. Zweitens, welche Dateiformate im eigenen Bestand dominieren, denn die Wissensbasis deckt laut README nur Text und gängige Bilder ab. Drittens, ob man Telegram- und E-Mail-Anbindung überhaupt aktivieren will, weil damit Zugangsdaten und Nachrichteninhalte in den Container wandern.
Der ehrlichste Umgang mit diesem Projekt ist, es als Werkbank zu behandeln. Die MVP-Version hat einen Rahmen geliefert, in dem Agenten, Wissensbasis und Workflows zusammenarbeiten. Der Kernel, der daraus ein Betriebssystem machen soll, ist noch nicht da.
Redaktionelles Fazit
Wer einen einzelnen Rechner besitzt, Docker ohnehin laufen hat und ausprobieren will, wie ein Agent auf lokale Dateien und E-Mails zugreift, kann OpenDAN 0.5.1 installieren und die Wissensbasis gegen das eigene Datenverzeichnis testen. Wer produktive Termin- oder Korrespondenzverwaltung braucht, sollte zuerst prüfen, ob der Telegram- und E-Mail-Anbindung in der eigenen Umgebung vertraut werden kann, und ob die Wissensbasis tatsächlich alle benötigten Dateiformate liest. Das Repository listet für die Wissensbasis nur Text- und gängige Bildformate als unterstützt; andere Formate sind offen markiert. Bis diese Lücke geschlossen ist, bleibt OpenDAN ein Experimentierfeld, kein Ersatz für bestehende Werkzeuge.
Community-Notizen