Setup-Service
Einmalige Installation auf Mac, Linux, WSL2 oder VPS inklusive Messenger-Pairing und Test-Task.
NanoClaw Guide fuer DACH
NanoClaw: der kleine KI-Agent fuer Container, WhatsApp und sichere Experimente.
NanoClaw ist interessant fuer Entwickler, Freelancer und kleine Teams, die OpenClaw-artige Assistenz wollen, aber den Code, die Containergrenzen und die Datenfluesse besser verstehen moechten.
Affiliate-Hinweis: Der VPS-Link ist gesponsert markiert.
Kurzantwort
Was ist NanoClaw?
NanoClaw ist ein leichter Open-Source-KI-Agent, der laut Projekt-README direkt auf Anthropic Agent SDK aufsetzt, Messenger wie WhatsApp, Telegram, Discord oder Slack anbinden kann, geplante Jobs unterstuetzt und Agenten in Linux-Containern isoliert. Der Kernnutzen liegt nicht in maximaler Feature-Breite, sondern in einem kleineren, besser auditierbaren Setup.
Positionierung
NanoClaw vs. OpenClaw
OpenClaw ist die groessere Plattform mit breiter Integrationsflaeche. NanoClaw argumentiert anders: weniger Code, weniger Konfigurationsflaeche, mehr Fokus auf Isolation. Das ist besonders relevant, wenn der Agent Shell-Befehle ausfuehren darf, Dateien lesen kann oder ueber Messenger von aussen erreichbar ist.
Fuer den Kurs ist NanoClaw deshalb ein eigenes Modul wert. Es spricht Suchintentionen wie "NanoClaw Deutsch", "OpenClaw Alternative", "KI Agent Container", "Claude Agent SDK WhatsApp" und "sicherer AI Agent VPS" an.
Entscheidungsmatrix
Wann NanoClaw sinnvoll ist
| Szenario | NanoClaw passt gut | Alternative pruefen |
|---|---|---|
| Privater Assistent | Wenn WhatsApp/Telegram, Speicher und geplante Tasks reichen. | OpenClaw, wenn sehr viele Integrationen direkt benoetigt werden. |
| Sicherheitsbewusstes Team | Wenn Containergrenzen, Mounts und kleinere Codebasis Prioritaet haben. | Hermes Agent, wenn Lernschleife und Multi-Plattform-Gateway wichtiger sind. |
| VPS-Betrieb | Wenn ein einzelner Agent dauerhaft Messenger und Cron-Jobs bedienen soll. | Managed Setup oder OpenClaw, wenn mehrere Nutzer/Integrationen geplant sind. |
| Lernen & Kurs | Wenn Teilnehmer Agent-Architektur wirklich verstehen sollen. | Reine No-Code-Agenten, wenn nur Oberflaechenbedienung gewuenscht ist. |
Setup-Pfad
So wuerde ich NanoClaw im Kurs aufbauen
- Lokales Labor: Repository klonen, Docker/Node/pnpm pruefen, ersten lokalen CLI-Agenten starten.
- Messenger-Kanal: Telegram oder WhatsApp anbinden und klaeren, welche Nachrichten der Agent wirklich sehen darf.
- Containergrenzen: Nur benoetigte Ordner mounten, keine privaten Home-Verzeichnisse pauschal freigeben.
- Memory: Gruppen- oder Agentenspeicher erklaeren, Loeschkonzept festlegen und sensible Daten vermeiden.
- Scheduled Jobs: Morning Briefing, GitHub-Monitoring oder Website-Check als erstes wiederkehrendes Beispiel bauen.
- VPS-Hardening: SSH-Key, Firewall, Updates, Backups, getrennte Nutzer, Logs und Neustartstrategie dokumentieren.
Kursmodule
NanoClaw-Inhalte, die monetarisierbar sind
Sicherheitscheck
Review von Mounts, API-Schluesseln, Messenger-Grenzen, Logs, Backups und Agentenrechten.
Automation Pack
Vorlagen fuer Briefings, Recherche, Kalender, GitHub, Website-Monitoring und Content-Ideen.
Hosting
NanoClaw lokal starten, VPS spaeter nutzen
Fuer den ersten Test reicht ein lokales System. Fuer Messenger-Erreichbarkeit und geplante Jobs ist ein kleiner VPS oft praktischer, solange Sicherheitsgrenzen und Backups sauber dokumentiert sind.
Quellen
Primaerquellen
- NanoClaw GitHub - README, Quick Start, Sicherheitsmodell und Support-Hinweise.
- NanoClaw Website - Produktpositionierung, Feature-Uebersicht und FAQ.
- OpenClaw GitHub - Vergleichspunkt fuer groessere Plattform-Setups.
- MCP Dokumentation - Grundlage fuer spaetere Tool-Integrationen.
FAQ
Haeufige Fragen zu NanoClaw
Ist NanoClaw besser als OpenClaw?
Nicht pauschal. NanoClaw ist interessant, wenn Auditierbarkeit und Isolation wichtiger sind als maximale Plattformbreite. OpenClaw ist staerker, wenn viele Integrationen und ein grosses Oekosystem im Vordergrund stehen.
Braucht NanoClaw zwingend einen VPS?
Nein. Lokal starten ist sinnvoll. Ein VPS wird interessant, wenn der Agent dauerhaft erreichbar sein, Messenger bedienen oder geplante Tasks ausfuehren soll.
Was ist das groesste Risiko?
Zu breite Berechtigungen. Ein Agent sollte nur die Ordner, Kanaele, Tools und Schluessel sehen, die fuer den jeweiligen Use Case wirklich noetig sind.