JSNexus: Mein privates digitales Betriebssystem

Es begann nicht mit Kubernetes. Das ist vermutlich eine der besseren Architekturentscheidungen des Projekts.

Ich wollte meine digitale Arbeit nicht länger über eine wachsende Anzahl einzelner Dienste verteilen, die zwar jeweils ihren Zweck erfüllen, zusammen aber kein verlässliches System bilden. Dateien lagen an einem Ort, Aufgaben an einem anderen, Dokumentation irgendwo dazwischen. Automatisierungen existierten, aber selten mit einem klaren Betriebsmodell. KI kam als neue Schicht hinzu und machte die Sache gleichzeitig spannender und gefährlicher.

Aus dieser Unruhe ist JSNexus entstanden: mein persönliches, souveränes Digital Operating System für Arbeit, Wissen, Kommunikation, Automatisierung und KI-Unterstützung.

Der Begriff Betriebssystem ist dabei bewusst größer als „Self-Hosting-Stack“. JSNexus ist keine hübsch sortierte Sammlung von Containern. Es ist der Versuch, Werkzeuge, Daten und Abläufe so zu verbinden, dass daraus eine beherrschbare Plattform wird.

Eine Plattform, keine App-Sammlung

Selbst gehostete Software zu installieren ist leicht. Sie dauerhaft zu betreiben, sauber zu aktualisieren, zu sichern und sinnvoll miteinander zu verbinden, ist der eigentliche Sport.

Deshalb beginnt JSNexus nicht bei Produktnamen, sondern bei Verantwortlichkeiten:

• OpenProject organisiert Projekte und verbindliche Arbeit.
• Nextcloud führt Dateien, Kalender, Kontakte und kollaborative Inhalte.
• BookStack und mein MindOS bewahren Dokumentation und dauerhaftes Wissen.
• Vaultwarden schützt Passwörter, Secrets und persönliche Zugänge.
• Stalwart bildet die eigene Mail- und Groupware-Basis.
• Forgejo führt interne Repositories, Änderungen und technische Zusammenarbeit.
• n8n automatisiert klar beschriebene und beobachtbare Abläufe.

Das Entscheidende ist nicht, dass diese Produkte zusammen auf einem Server laufen. Entscheidend ist, dass jedes System eine eindeutige Rolle besitzt und die fachliche Wahrheit dort bleibt, wo sie hingehört.

Die Fachsysteme führen ihre Daten

Viele Integrationsprojekte beginnen mit der Idee einer zentralen Datenplattform. Irgendwann liegt dort eine zweite, leicht veraltete Kopie von allem. Danach braucht man Synchronisation, Konfliktlösung und erstaunlich viele Meetings mit sich selbst.

JSNexus verfolgt einen anderen Ansatz. OpenProject bleibt die Quelle für Projekte. Nextcloud bleibt die Quelle für Dateien und Termine. BookStack bleibt die Quelle für betriebliche Dokumentation. Git bleibt die Quelle für Code, Infrastruktur und versionierte Automatisierungen.

Die Systeme werden über kleine, nachvollziehbare Verträge verbunden. Kontext darf zusammengeführt werden, aber die Verantwortung für die Daten wird nicht verwischt. Das klingt unspektakulär. Genau deshalb funktioniert es.

Langweilige Infrastruktur ist ein Kompliment

Die technische Grundlage besteht aus getrennten Docker-Compose-Stacks und einem Git-geführten Betriebsmodell. Jede relevante Änderung wird lokal vorbereitet, geprüft, versioniert und kontrolliert ausgerollt.

Ein Stack hat eine klare Aufgabe, explizite Persistenz, definierte Netzwerke, Healthchecks und einen dokumentierten Pfad für Update, Sicherung und Wiederherstellung. Container-Images sind fest versioniert. Laufzeitdaten und Secrets gehören nicht ins Repository.

Das ist absichtlich keine Plattform für architektonische Selbstverwirklichung. JSNexus soll von einer Person verstanden, gewartet und im Fehlerfall wieder aufgebaut werden können. Kleine, sichtbare Komplexität schlägt große, elegante Magie – besonders nachts um zwei.

Ein Portal statt zwölf Startseiten

Eine Plattform wird nicht dadurch alltagstauglich, dass ihre Architektur sauber dokumentiert ist. Sie braucht einen ruhigen Einstiegspunkt.

Das JSNexus-Portal bündelt deshalb die persönliche Arbeitsoberfläche: anstehende Aufgaben, Termine, Systemzustände, Suche, Automatisierungen und den direkten Weg in die zuständigen Fachsysteme. Es soll nicht jede Anwendung nachbauen. Es soll Orientierung geben und Reibung entfernen.

Dahinter bleibt die Trennung erhalten. Das Portal zeigt Kontext und stößt klar definierte Abläufe an, wird aber nicht zur nächsten Universal-Datenbank.

KI darf nicht einfach alles

Spätestens mit ChatGPT, Codex und Open WebUI wurde aus der privaten Cloud eine KI-fähige Arbeitsplattform. Die spannende Frage war nicht, welches Modell die längsten Antworten schreibt. Die entscheidende Frage war: Wie bekommt eine Assistenz genau den benötigten Kontext, ohne pauschalen Zugriff auf das gesamte digitale Leben zu erhalten?

JSNexus trennt deshalb drei Dinge bewusst:

• Ein Context Gateway liefert begrenzten, nachvollziehbaren Kontext aus freigegebenen Quellen.
• Retrieval findet relevante Informationen, ohne die Fachsysteme als Quelle der Wahrheit zu ersetzen.
• Aktionen laufen über einen eigenen, engeren Vertrag mit Berechtigungen, Bestätigung und Protokollierung.

Lesen und Handeln sind nicht dasselbe. Eine Assistenz darf eine Aufgabe zusammenfassen, ohne sie verändern zu dürfen. Sie darf einen Entwurf vorbereiten, ohne ihn automatisch zu veröffentlichen. Und wenn sie handeln soll, muss der Weg sichtbar, begrenzt und rückverfolgbar sein.

Genau diese Trennung macht KI im Alltag nützlich. Nicht maximale Autonomie, sondern passende Autonomie.

Automatisierung braucht einen Fehlerpfad

n8n verbindet viele dieser Abläufe. Ein täglicher Überblick kann Aufgaben, Termine und relevante Hinweise aus mehreren Systemen zusammenführen. Wiederkehrende Prozesse lassen sich auslösen, ohne jedes Mal dieselben Klicks zu wiederholen.

Aber ein grüner Workflow ist noch kein Beweis für ein richtiges Ergebnis. Eine Quelle kann ausgefallen sein, ein Teilschritt kann still degradiert laufen oder ein Zielsystem eine Anfrage nur teilweise verarbeitet haben.

Deshalb gehören Fehlerbehandlung, Protokollierung, Wiederanlaufverhalten und sichtbare Zustände zum Vertrag einer Automatisierung. Ein Ablauf, den man nicht sicher stoppen oder nachvollziehen kann, ist keine Erleichterung. Er ist lediglich ein schnellerer Weg zu einem schwer erklärbaren Problem.

Backup ist erst nach dem Restore ein Feature

Eine private Plattform besitzt keinen anonymen Betriebstrupp, der im Hintergrund schon irgendwie alles repariert. Deshalb ist Wiederherstellbarkeit eines der wichtigsten Architekturziele von JSNexus.

Relevante Zustände werden nicht nur gesichert. Für die Dienste existieren konkrete Wiederherstellungspfade, Prüfungen und eine definierte Reihenfolge. Monitoring betrachtet nicht nur, ob ein Container läuft, sondern auch, ob Dienste erreichbar sind, Backups aktuell bleiben und zentrale Funktionen tatsächlich antworten.

Das verändert die Perspektive: Ein Dienst gilt nicht als fertig, wenn die Startseite erscheint. Er gilt als betreibbar, wenn Update, Überwachung, Sicherung und Wiederherstellung geklärt sind.

Was ich dabei gelernt habe

JSNexus ist über viele kleine Entscheidungen gewachsen. Einige Erkenntnisse haben sich dabei wiederholt:

• Datenhoheit ohne Betriebsdisziplin ist nur ein eigener Server mit mehr Verantwortung.
• Eine klare Quelle pro Information verhindert mehr Probleme als die nächste intelligente Synchronisation.
• Gute Automatisierung macht ihren Zustand sichtbar und ihren Fehlerfall langweilig.
• KI wird besser, wenn Kontext und Berechtigungen präziser werden – nicht wenn man ihr vorsorglich alles öffnet.
• Dokumentation, Monitoring und Restore-Tests sind keine Anhänge. Sie sind Teil des Produkts.

Ein System, das nie ganz fertig sein muss

JSNexus ist kein abgeschlossenes Produkt. Werkzeuge werden ersetzt, Verträge geschärft und neue Fähigkeiten ergänzt. Entscheidend ist, dass die Plattform dabei beherrschbar bleibt.

Das Ziel ist nicht, jeden verfügbaren Dienst selbst zu hosten. Das Ziel ist eine ruhige, souveräne Arbeitsumgebung, in der Technik ihren Zweck erfüllt: weniger Reibung, bessere Orientierung und mehr Raum für die eigentliche Arbeit.

JSNexus ist ein privates Projekt. Der technische Unterbau und die Architekturentscheidungen werden intern versioniert und dokumentiert; dieser Artikel ist der öffentliche Einblick in Idee, Prinzipien und Arbeitsweise.