OpenClaw kann deutlich nützlicher werden, wenn man Dienste anbindet, die für bestimmte Aufgaben bereits optimiert sind. Anstelle in zu vielen Skills das Rad jedes Mal neu zu erfinden nutzt man einfach was es schon gibt und lässt das nur noch aufrufen.

1. Warum nicht nur OpenClaw?

Eins vorweg, OpenClaw funktioniert auch ohne zusätzliche Dienste und kann mit ein wenig Prompting viele Aufgaben automatisieren. Es kann Secrets selbst verwalten, Scripte als Dateien erzeugen, Kalender als Markdown abspeichern. Die Frage ist warum man sich die Mühe machen sollte, mehrere Docker-Container aufzusetzen und OpenClaw mit jedem einzelnen aufwändig zu verbinden.

Die Antwort: Kontrolle und der Erhalt bekannter Workflows des Nutzers. Statt einer Black Box, die ihre Daten irgendwo im Container ablegt, bekommt man Transparenz, Datenhoheit und die Möglichkeit, Daten in der gewünschten Form anzuschauen (bspw. den Kalender in der Kalender-App) und selbst zu ändern.

2. Das Setup auf einen Blick

OpenClaw wird durch folgende selbst gehostete Services ergänzt:

Service	Rolle	Anbindung
Vaultwarden	Secret-Speicher (API-Keys, Tokens)	bw CLI + Resolver-Script + Env-Injector
Forgejo	Git-Repository für Helper-Scripte	MCP-Server (stdio) + Git über SSH
Nextcloud	Geteilter Kalender für Events	CalDAV/WebDAV (curl-Skripte)
Anytype	Strukturierte Wissensdaten (“Second Brain”)	HTTP-API + MCP-Tools

Alle Services laufen im lokalen Netzwerk. Nichts verlässt die eigene Infrastruktur.

3. Wie es funktioniert

Vaultwarden (Secrets)

API-Keys und Tokens liegen im Vault, nicht in Config-Dateien. Ein Resolver holt gezielt Secrets beim Start, ein Env-Injector schreibt sie in eine .env, aus der OpenClaw ${VAR}-Substitution macht. Die Config enthält damit nur Referenzen.

Forgejo (Scripte)

Alle Helper-Scripte des Assistenten liegen in einem privaten Git-Repo. Der Assistent committet Änderungen über SSH; ein MCP-Server stellt Repo-Verwaltung, Issues und Datei-Operationen als Tools bereit.

Nextcloud (Kalender)

Gefundene Events werden per CalDAV direkt in einen eigenen Assistenten-Kalender geschrieben, der mit dem Hauptuser geteilt wird. Zusätzlich lokale ICS-Datei und Anytype-Objekte als Redundanz.

Anytype (Wissen)

Strukturierte Objekte in einem dedizierten Space: Jobs, Events, Entscheidungen, Quellen, Personen, Projekte, tägliche Notizen. Jeder Typ hat typisierte Properties (select, number, date, url — keine Text-Catch-alls). MCP-Tools für Einzel-Operationen, direkte HTTP-API für Bulk-Reads.

4. Vorteile

• Single Source of Truth: Secrets im Vault, Scripte im Git, Events im Kalender, Wissen in Anytype. Vier sichtbare, durchsuchbare Orte statt verstreuter Config-Dateien.
• Nutzer hat volle Kontrolle: Jeder Service hat eine eigene UI. Man kann Secrets ändern, Scripte reviewen, Events verschieben, Wissen durchsuchen — ohne den Assistenten anzufassen.
• Datenhoheit: Nichts verlässt das eigene Netzwerk. Keine Cloud-Provider, die Policies ändern oder Daten sperren.
• Modularität: Jede Anbindung ist unabhängig. Ein Service down? Die anderen funktionieren weiter. Runtime-Kopien und .env-Pufferung machen das robust.
• Nachvollziehbarkeit: Git-History für Scripte, Event-Log im Vault, strukturierte Objekte in Anytype.

5. Nachteile und Risiken

• Wartungsaufwand: Da es ein selbst gebasteltes Setup ist, können durch Container-Updates Workflows brechen. Es kann sehr gut sein, dass des öfteren mal manuell nachgebessert werden muss.
• Security: Man muss selbst über mögliche Schwachstellen des Setups nachdenken und diese absichern.

6. Was zu tun ist

Wenn du das Setup nachbauen willst:

1. Vaultwarden aufsetzen → bw CLI installieren → Resolver- und Env-Injector-Skripte schreiben → alle Secrets als Login-Items anlegen → ${VAR}-Referenzen in der OpenClaw-Config verwenden.
2. Forgejo aufsetzen → Assistenten-Account mit API-Token anlegen → SSH-Key hinterlegen → forgejo-mcp als MCP-Server eintragen → Helper-Scripte in ein privates Repo committen.
3. Nextcloud aufsetzen → eigenen User-Account für den Assistenten anlegen → Kalender erstellen und teilen → CalDAV-Skripte mit curl schreiben.
4. Anytype installieren → Space für den Assistenten anlegen → API-Key im Vault speichern → Typen und Properties definieren → MCP-Tools für Einzel-Operationen, HTTP-API für Bulk-Reads.

Offene TODOs nicht vergessen: HTTPS für Vaultwarden, Docker Secrets statt Env-Vars, API-Key-Rotation-Policy definieren.

7. Fazit

Die Anbindung an selbst gehostete Services ist kein “einmal konfigurieren und vergessen” sondern ein zusammengesetztes System mit Wartungsaufwand. Aber dafür erhält man Transparenz, Datenhoheit und Anpassbarkeit. Für jemanden, der sowieso selbst hostet und Lust auf Basteln hat, kann das ein spaßiges Hobbyprojekt sein. Für jemanden, der “einfach nur einen Assistenten” will, ist es Overkill.