# Moltbot auf Synology NAS installieren **Status (Jan 2026):** Erfolgreich installiert und betriebsbereit. Diese Anleitung beschreibt die empfohlene Methode zur Installation von Moltbot auf einer Synology DiskStation unter Verwendung des offiziellen Setup-Skripts via SSH. --- ## 1. Voraussetzungen * **DSM 7.x** mit installiertem **Container Manager**. * **SSH-Zugang** zur Synology NAS ist aktiviert (Systemsteuerung → Terminal & SNMP → SSH). --- ## 2. Installation (Via SSH & Setup-Skript) Die Installation erfolgt direkt auf der Kommandozeile der DiskStation. ### Schritt 1: Ordnerstruktur auf dem NAS anlegen Zuerst legen wir die Verzeichnisse an, in denen die Konfiguration und die Arbeitsdaten von Moltbot persistent gespeichert werden. ```bash # Pfad für die Moltbot-Installation erstellen mkdir -p /volume1/docker/moltbot # Unterordner für Konfiguration und Workspace anlegen mkdir -p /volume1/docker/moltbot/config mkdir -p /volume1/docker/moltbot/workspace # WICHTIG: Berechtigungen setzen, damit der Container schreiben darf sudo chown -R 1000:1000 /volume1/docker/moltbot/config /volume1/docker/moltbot/workspace ``` ### Schritt 2: Repository klonen und Setup ausführen Nun klonen wir das offizielle Moltbot-Repository und starten das Setup-Skript mit den richtigen Pfadangaben. ```bash # In das vorbereitete Verzeichnis wechseln cd /volume1/docker/moltbot # Moltbot-Repository von GitHub klonen git clone https://github.com/moltbot/moltbot.git cd moltbot # Umgebungsvariablen für die persistenten Pfade setzen export CLAWDBOT_CONFIG_DIR="/volume1/docker/moltbot/config" export CLAWDBOT_WORKSPACE_DIR="/volume1/docker/moltbot/workspace" # Das offizielle Setup-Skript ausführen ./docker-setup.sh ``` ### Schritt 3: Interaktives Onboarding Das Skript startet einen interaktiven Onboarding-Prozess. Folgen Sie den Anweisungen. Die Standardwerte sind in der Regel eine gute Wahl. Am Ende startet der Moltbot-Gateway-Container automatisch. --- ## 3. Zugriff auf die Control UI (Aktueller Stand) ### Das "Secure Context"-Problem Moltbot erfordert aus Sicherheitsgründen einen "sicheren Kontext" (HTTPS oder `localhost`) für den Zugriff auf das Web-Interface. Ein direkter Aufruf über `http://:18789` schlägt daher fehl und führt zu einer `disconnected (1008)`-Fehlermeldung. ### Lösung: SSH-Tunnel Die aktuell funktionierende und sichere Methode für den Zugriff ist ein SSH-Tunnel. Dieser leitet den Port des Containers auf Ihren lokalen PC um, sodass der Zugriff über `localhost` erfolgt. **Befehl zum Aufbau des Tunnels (auf Ihrem PC ausführen):** ```powershell # Ersetze mit der IP-Adresse Ihrer DiskStation ssh -N -L 28789:127.0.0.1:18789 root@ ``` **Zugriff im Browser:** Solange der SSH-Tunnel aktiv ist, können Sie die Moltbot UI auf Ihrem PC unter folgender Adresse erreichen: `http://127.0.0.1:28789/` Denken Sie daran, den beim Onboarding generierten Token an die URL anzuhängen (z.B. `?token=...`), falls erforderlich. --- ## 4. Nächste Schritte: Zugriff vereinfachen Der Zugriff über einen SSH-Tunnel ist sicher, aber für den täglichen Gebrauch und den Zugriff von unterwegs unpraktisch. **Offener Task:** * Einrichtung eines **Reverse Proxys** auf der Synology DiskStation. * **Ziel:** Moltbot über eine sichere **HTTPS**-URL (z.B. `https://moltbot.meine-domain.de`) erreichbar zu machen. Dies erfüllt die "Secure Context"-Anforderung und macht den manuellen Aufbau eines SSH-Tunnels überflüssig. [STRATEGIE] Das war ein technischer Stellungskrieg, aber wir haben die Architektur jetzt "Synology-proof" und hochfunktional. Der entscheidende Durchbruch war die Abkehr von der automatisierten Konfiguration hin zur **expliziten Architektur-Kontrolle** (Root-User, manuelle JSON-Injektion und Runtime-Bootstrapping). Hier ist der destillierte **Setup-Guide 2026** für dein Gitea-Repository. --- # 🦞 Moltbot Synology Deployment Guide (Feb 2026) ## 1. Strategischer Kontext Dieses Setup dient als Backend für die **GTM-Engine** von RoboPlanet. Es ist darauf optimiert, auf einer Synology DiskStation stabil zu laufen, Berechtigungskonflikte zu vermeiden und eine vollwertige **Python/Pip/Git-Umgebung** für automatisierte Workflows bereitzustellen. ## 2. Infrastruktur (Host-Ebene) Bevor der Container startet, muss die Verzeichnisstruktur auf der DiskStation exakt so vorbereitet sein. Dies verhindert "Bind mount"-Fehler und sichert die Datenpersistenz. ```bash # Hauptverzeichnis mkdir -p /volume1/docker/moltbot # Unterordner für saubere Trennung mkdir -p /volume1/docker/moltbot/storage # Datenbank & State (~/.clawdbot) mkdir -p /volume1/docker/moltbot/config # Statische Konfiguration mkdir -p /volume1/docker/moltbot/workspace # Arbeitsbereich für Agenten-Scripte mkdir -p /volume1/docker/moltbot/secrets # API-Keys & Zertifikate # Rechte-Management (Zwingend für Synology) # Wir setzen 1000:1000 (Node) oder nutzen user:root im Container sudo chown -R 1000:1000 /volume1/docker/moltbot ``` ## 3. Konfiguration (Die "Ground Truth") Manuelle Erstellung der Konfiguration, um Validierungsfehler der CLI zu umgehen. Erstelle die Datei `/volume1/docker/moltbot/config/moltbot.json`: ```json { "gateway": { "mode": "local", "bind": "lan", "port": 18789, "auth": { "token": "DEIN_GATEWAY_TOKEN" } }, "channels": { "telegram": { "enabled": true } } } ``` ## 4. Docker-Compose (Die Engine) Die finale `docker-compose.yml`. Zentrale Entscheidungen: - **user: root**: Erforderlich für die Installation von System-Paketen (Python) zur Laufzeit. - **command-Bootstrap**: Installiert Python & Git bei jedem Start, falls das Image aktualisiert wird. - **auth-profiles Injection**: Schreibt den Gemini-Key direkt in den Agent-Speicher. ```yaml services: openclaw-gateway: image: ghcr.io/openclaw/moltbot:main container_name: openclaw-gateway user: root environment: MOLTBOT_STATE_DIR: /home/node/.clawdbot OPENCLAW_GATEWAY_TOKEN: ${OPENCLAW_GATEWAY_TOKEN} TELEGRAM_BOT_TOKEN: ${TELEGRAM_BOT_TOKEN} GEMINI_API_KEY: ${GEMINI_API_KEY} HOME: /home/node volumes: - /volume1/docker/moltbot/storage:/home/node/.clawdbot - /volume1/docker/moltbot/workspace:/home/node/.clawdbot/workspace - /volume1/docker/moltbot/config/moltbot.json:/home/node/.clawdbot/moltbot.json:ro ports: - "18789:18789" init: true restart: unless-stopped command: > sh -lc ' apt-get update && apt-get install -y python3 python3-pip git build-essential mkdir -p /home/node/.clawdbot/agents/main/agent echo "{\"google\": {\"apiKey\": \"$${GEMINI_API_KEY}\"}}" > /home/node/.clawdbot/agents/main/agent/auth-profiles.json exec node dist/index.js gateway --bind lan ' openclaw-cli: image: ghcr.io/openclaw/moltbot:main container_name: openclaw-cli user: root environment: MOLTBOT_GATEWAY_URL: ws://openclaw-gateway:18789 MOLTBOT_GATEWAY_TOKEN: ${OPENCLAW_GATEWAY_TOKEN} volumes: - /volume1/docker/moltbot/storage:/home/node/.clawdbot - /volume1/docker/moltbot/workspace:/home/node/.clawdbot/workspace entrypoint: ["node", "dist/index.js", "--gateway", "ws://openclaw-gateway:18789"] stdin_open: true tty: true ``` ## 5. Operative Key-Entscheidungen (Review) 1. **Pfad-Konsistenz:** Umstellung von `.openclaw` auf `.clawdbot` (Projekt-Migration 2026 gefolgt). 2. **Bind-Parameter:** Wechsel von `0.0.0.0` auf `lan`, da das Gateway-Modul spezifische Keywords für das Interface-Binding verlangt. 3. **CLI-Targeting:** Die CLI wurde über den `entrypoint` fest auf den Gateway-Service verdrahtet, um den Loopback-Fehler (`127.0.0.1`) innerhalb des Docker-Netzwerks permanent zu beheben. 4. **Pairing-Prozess:** Initialisierung via Telegram erfordert ein einmaliges `pairing approve` über die CLI, um die User-ID des Besitzers zu verknüpfen. ## 6. Wartung - **Python-Module:** Können über `docker exec -it openclaw-gateway pip install ` nachinstalliert werden. - **Updates:** `docker compose pull && docker compose up -d` (Das Bootstrap-Skript installiert Python automatisch nach). --- [STATUS] Das System läuft. Python ist installiert. Gemini ist autorisiert. Die GTM-Engine ist bereit für den ersten "Whale Hunting" Task. Was ist die erste operative Aufgabe, die der Bot für dich erledigen soll? Gitea-Clone oder Prospecting-Analyse? 🦞