ClawdBot Setup 2026: Self-Hosted KI wie Siri – Hetzner VPS, Telegram, Memory & Skills [Video]

ClawdBot: „Die Siri, die wir nie bekommen haben“ – Self-Hosted Assistant mit Memory, Telegram & Skills (Full-Setup, Januar 2026)

Stand: 28.01.2026


VelvetShark bringt die Stimmung vieler Tech-Nutzer perfekt auf den Punkt: Siri kann bis heute kaum Kontext halten – selbst simple Präferenzen oder Dinge „von gestern“ verpuffen oft. Sein Gegenentwurf heißt ClawdBot: ein self-hosted KI-Assistent, der nicht in einer App „wohnt“, sondern in den Messengern, die ohnehin jeden Tag offen sind (Telegram/WhatsApp/Slack/Discord). Der Kniff ist dabei nicht nur die Oberfläche, sondern die Kombination aus 24/7-Betrieb, persistenter Erinnerung (Memory), proaktiven Nachrichten (z. B. Morning Briefings) und Skills, die echte Aktionen ermöglichen – von Web-Recherche über Mail/Calendar bis hin zu Browser-Automation. Das ist der Moment, in dem „Chatbot“ zur Agent-Infrastruktur wird: nicht nur antworten, sondern handeln.

Direkt zum Inhaltsverzeichnis ✅

In diesem Beitrag werden VelvetSharks Setup-Schritte (VPS bei Hetzner, Installation, Wizard, Telegram-Pairing, Skills, Remote-UI) verständlich nachgezeichnet – und zugleich die entscheidende Kehrseite sauber eingeordnet: Ein Agent mit echten Rechten ist kein Spielzeug. Wer tiefer in Umbenennung/Einordnung, typische Angriffsflächen und Hardening eintauchen will, findet den passenden Hintergrund-Guide hier: Moltbot/ClawdBot: Features, Risiken & Security-Guide.

Das Wichtigste auf einen Blick

  • These des Videos: ClawdBot ist „die Siri, die wir wollten“ – dank Memory, Messenger-Integration und Proaktivität.
  • Setup-Idee: 24/7-Betrieb über einen günstigen VPS (~5 $/Monat) statt Laptop, der ständig schlafen geht.
  • Architektur (Kern): Gateway (Eingang + Cron), Agent (LLM/Provider), Skills (Funktionen), Memory (persistenter Kontext).
  • Interface: Fokus auf Telegram (sauberes Bot-Konzept + Pairing/Allowlisting).
  • Security-Priorität: Isolation, Least Privilege, keine offenen Ports, sichere Remote-Zugriffe (z. B. Tailscale), sensible Accounts nur mit Konzept.

1) Worum geht’s im Video?

VelvetShark liefert einen „Full Setup“-Walkthrough, der weniger Buzzword-Show als vielmehr praktische Systemführung ist: Er startet mit einem Vergleich zu Siri/Google Assistant (fehlender Kontext, kein echtes Gedächtnis, kaum echte Assistenz), stellt dann ClawdBot als self-hosted 24/7-Assistenten vor und geht anschließend Schritt für Schritt durch die Einrichtung auf einem günstigen VPS (im Video: Hetzner, grob ~5 $/Monat). Besonders nützlich ist dabei, dass er nicht nur „installiert“, sondern die Bausteine erklärt, damit klar wird, wo die Macht – und wo das Risiko – sitzt: Das Gateway als Eingangstor (inkl. Scheduling/Cron), der Agent als Modell-Provider-Schicht (Claude/OpenAI/Gemini/lokal), Skills als Capability-Layer, und Memory als persistente Kontextbasis. Danach zeigt er den Moment, der für viele Leser/Viewer der „Aha“-Punkt ist: Erste Nachricht in Telegram – und der Assistent läuft nicht „in einer App“, sondern dort, wo man ohnehin schreibt.

Video-Quickfacts (VelvetShark)

  • Titel: “ClawdBot: The self-hosted AI that Siri should have been (Full setup)”
  • Veröffentlichung: 09.01.2026
  • Hook: „Assistent mit Memory, der dich proaktiv anschreibt – in Telegram/WhatsApp“
  • Setup-Fokus: Hetzner-VPS + Wizard + Telegram + Skills + Remote-UI
  • Warnung im Video: „Real agent with real powers“ – Security-Doku lesen, bevor sensible Accounts dran hängen

2) „Siri sollte so sein“: Was ClawdBot grundsätzlich anders macht

Der Siri-Vergleich ist rhetorisch stark, aber technisch gut begründbar: Klassische Voice-Assistants wirken für viele Nutzer wie stateless Command-Interfaces – sie reagieren auf einen Satz, verlieren aber Kontext, Präferenzen und fortlaufende Aufgaben oft sehr schnell. ClawdBot dreht das Modell um: Es ist kein „Assistent, den man öffnet“, sondern ein dauerhaft laufender Dienst, der über Messenger erreichbar ist und damit zwei psychologische Hürden entfernt: (1) den App-Wechsel und (2) die Notwendigkeit, „dran zu denken“. Der zweite Unterschied ist die Persistenz: Memory ist nicht nur „Chat-Historie“, sondern eine Struktur, die Kontexte, Präferenzen und Aufgaben halten kann, sodass nicht jedes Gespräch bei null startet. Der dritte Unterschied ist die Proaktivität: Der Bot kann dich anschreiben (Briefings, Alerts, Reminder), statt nur zu warten. Und der vierte Unterschied ist die wichtigste – und riskanteste: Agency. Sobald ein Assistent nicht nur Text liefert, sondern Tools/Skills nutzt, Dateien liest, Browser steuert oder Integrationen bedient, ist er nicht mehr „Siri“, sondern eine Automation-Schicht. Genau hier entsteht der Nutzen (Zeitgewinn, weniger Kontextwechsel, weniger Kleinkram) – und genau hier beginnt Security (Rechte, Tokens, Angriffsfläche, Fehlaktionen).

3) Architektur erklärt: Gateway, Agent, Skills, Memory

VelvetSharks Architektur-Skizze ist die Stelle, an der aus „Cooles Tool“ ein verständliches System wird. Das Gateway ist die Frontdoor: Es nimmt Nachrichten aus Telegram/WhatsApp & Co. entgegen, verwaltet Pairing/Policies (wer darf überhaupt Befehle geben?) und übernimmt häufig auch das Scheduling (Cron) für proaktive Jobs. Der Agent ist die Denk-Schicht – also der Provider/LLM, der Antworten und Entscheidungen liefert (Claude/OpenAI/Gemini oder lokal). Skills sind die Funktions-Erweiterungen: Web-Recherche, Mail/Calendar, Browser-Automation, Developer-Tools, Notizen-Wikis, Transkription – je nach Setup. Und Memory ist die Persistenz-Schicht: Informationen, die nicht im LLM „verankert“ sind, sondern als Datenbasis auf dem eigenen System liegen, sodass Kontext über Tage/Wochen tragfähig bleibt. Wichtig als Lesart: Das „Modell“ ist austauschbar, Memory ist es nicht. Genau daraus ergibt sich ein entscheidender Praxisvorteil: Wenn ein Provider Probleme macht (API-Änderungen, Limits), kann man – zumindest konzeptionell – den Brain austauschen, während Memory/Automationen/Workflows weiterleben. Wer das versteht, versteht auch, warum self-hosted Agenten 2026 so schnell Fahrt aufnehmen: Sie sind weniger Produkt, mehr persönliche Infrastruktur.

4) Warum ein VPS (~5 $) der pragmatische Sweet Spot ist

Die VPS-Argumentation ist simpel – und deshalb überzeugend: Ein Assistant, der proaktiv sein soll, muss laufen, wenn du nicht aktiv bist. Auf dem Laptop endet 24/7 spätestens beim Zuklappen. Ein VPS ist dagegen „kleiner Rechner in der Cloud“, immer an, sauber separiert. Der Preisbereich um ~5 $/Monat ist dabei psychologisch und technisch attraktiv: günstig genug, um es auszuprobieren, aber stark genug, um Gateway + Agent + Memory + ein paar Skills solide zu betreiben. Gleichzeitig zwingt ein VPS zu einem gesünderen Sicherheitsdenken: Du behandelst den Bot nicht wie eine App, sondern wie einen Mini-Server. Damit kommen automatisch Fragen ins Spiel, die bei lokalem „einfach mal starten“ oft vergessen werden: Wer hat SSH-Zugang? Läuft alles als root? Sind Ports offen? Wo liegen Tokens? Wie mache ich Updates? Genau diese Fragen entscheiden später darüber, ob ClawdBot „Produktivität“ ist – oder ein Einfallstor. In VelvetSharks Flow wirkt der VPS deshalb wie der reale, vernünftige Einstieg: Always-on, separiert, kontrollierbar und deutlich leichter zu härten als „läuft halt auf meinem Hauptrechner mit allem drauf“.

5) Hetzner-Setup: Server anlegen, updaten, absichern

Im Video startet der Setup-Teil klassisch: VPS anlegen (Standort, Ubuntu), einloggen, System aktualisieren, reboot nach Kernel-Updates. Entscheidend ist aber die Sicherheits-Logik, die VelvetShark direkt mitliefert: Er empfiehlt Tailscale, um den Server in ein privates Netz zu hängen – damit man möglichst wenig über öffentliche Ports lösen muss. Das ist mehr als „nice to have“: Für Agent-Systeme ist Remote-Access eine der größten Fehlerquellen. „Ich öffne mal eben Port X ins Internet“ wird in diesem Kontext schnell zu „Ich habe eine Admin-UI exponiert, die Aktionen auslösen kann“. Zusätzlich zeigt er eine Best Practice, die banal klingt, aber oft ignoriert wird: dedizierter User statt root. Das reduziert nicht alle Risiken, aber es verhindert eine ganze Klasse unnötiger Eskalationen und macht Tooling/Permissions sauberer. Wer das Setup als Checkliste liest, kann es so übersetzen: erst Infrastruktur stabil (Updates, SSH), dann Access sicher (Tailscale/Private Network), dann Prinzip Least Privilege (User/Policies), erst dann Agent installieren. Genau diese Reihenfolge trennt „schnell irgendwie“ von „produktiver Betrieb“.

6) Installation: Prerequisites, Build, Wizard

VelvetShark geht nicht nur über eine Quick-Install, sondern zeigt einen „hackable“ Weg (Repo klonen, dependencies installieren, build, optional Web-UI). Das wirkt auf Einsteiger zuerst schwerer, ist aber in der Praxis oft die robustere Wahl: Updates, Debugging und Skill-Entwicklung werden einfacher, weil das Projekt lokal als Codebasis vorliegt. Zu den typischen Prerequisites zählen Node.js/Package-Manager (z. B. pnpm), teils Homebrew (für Skill-Installationspfade) und – in seinem Setup – zusätzlich Claude Code, das während des Wizards als „zweites Gehirn“ dient: Er lässt Claude Code parallel laufen, um bei Optionen/Fehlern direkt Fragen zur Codebasis zu stellen. Das ist ein sehr 2026-Move: Der Agent wird eingerichtet, während ein anderer Agent als Live-Doku + Debug-Assistent dient. Der Wizard selbst ist der zentrale Punkt: Hier werden Provider, Gateway-Optionen, Ports/Bindings, Chat-Plattformen (Telegram) und Skills konfiguriert. Wer hier gedankenlos „alles aktivieren“ klickt, baut sich die maximale Angriffsfläche – wer hier minimal startet, bekommt einen stabilen Kern, den man später erweitert. Das ist die richtige mentale Haltung: Wizard ist nicht „Onboarding“, Wizard ist Threat-Modeling in UI-Form.

7) Telegram als Interface: BotFather, Token, Pairing & Policies

Telegram ist im Video nicht zufällig die erste Wahl: Telegram hat ein klares Bot-Konzept, Tokens, und lässt sich sauber pairen. VelvetShark zeigt den praktischen Ablauf: Bot in Telegram via BotFather anlegen, Bot-Token in den Wizard/Config übernehmen, danach die kritische Phase: Pairing/Allowlisting. Entscheidend ist nicht, dass „der Bot antwortet“, sondern dass nur du ihm Befehle geben kannst. Im Flow sieht man genau das: Der Bot ist zunächst „not linked“, dann wird per Pairing-Command/Code der Sender freigeschaltet. Das ist Security-Grundhygiene – und für Agenten essenziell. Denn ab hier ist der Bot nicht nur „Chat“, sondern potentiell ein System, das Skills ausführt, Jobs schedult, mit Accounts interagiert. Wer Telegram nutzt, sollte deshalb immer zwei Dinge sauber halten: (1) Pairing/Policies restriktiv, (2) Tokens nicht in Logs/Chats/Notizen leaken. In der Praxis ist Telegram damit ein guter Start: Weniger Chaos als WhatsApp, wo Nummern/Inbound Messages schnell zum Problem werden können, und weniger Team-Komplexität als Slack/Discord, wenn man noch nicht weiß, welche Rollen/Policies man braucht.

8) Skills: Was sinnvoll ist – und was nur neue Angriffsfläche schafft

Skills sind der Turbo – und der Risikomultiplikator. VelvetShark empfiehlt sinngemäß eine Starter-Mischung, die direkt Nutzen bringt: Web-Research, Browser-Automation, Email/Calendar (wenn wirklich gebraucht), Developer-Tools (für Coding Agents), Transkription (Voice Notes), Summarizer (URLs/PDFs/YouTube). Gleichzeitig zeigt er, wie Skills praktisch über Web-UI installiert/aktiviert werden und dass manche Skills Tokens brauchen (z. B. Social-Posting). Genau hier liegt die wichtigste Regel: Jeder Skill ist ein neuer Permission-Scope. Ein Skill, der „nur“ web recherchiert, ist vergleichsweise harmlos. Ein Skill, der Mail sendet, Kalender bearbeitet, GitHub pusht oder Social Accounts steuert, ist im Effekt ein Account-Operator. Deshalb gilt als Setup-Prinzip: zuerst Skills, die „lesen“ und „zusammenfassen“, dann Skills, die „handeln“ – und bei „handeln“ immer mit Bestätigungslogik, dedizierten Accounts und klaren Grenzen. Wer ClawdBot wirklich produktiv betreiben will, sollte Skills wie eine Firewall behandeln: minimal starten, Nutzen messen, dann gezielt öffnen.

9) Proaktivität: Morning Briefings & Cron als „Superpower“

Der Punkt „es schreibt dich an“ ist im Video der eigentliche Siri-Moment: Nicht du gehst zum Assistenten, der Assistent kommt zu dir – mit Briefings, Alerts, Remindern. Technisch landet das oft im Gateway/Scheduler (Cron), inhaltlich ist es eine kleine Revolution im Workflow: Statt fünf Apps zu öffnen (Mail, Kalender, News, To-dos, Research) bekommst du eine kuratierte Nachricht, idealerweise mit Links/Actions. VelvetShark nennt Beispiele wie tägliche Research-Zusammenfassungen zu Topics, Reminder auf Basis von Kalender/Email, und Monitoring („wenn X passiert, melde dich“). Der praktische Mehrwert entsteht durch zwei Dinge: (1) Timing (z. B. 08:00 Briefing), (2) Kontext (Memory + Skills). Für Redaktionen/Creator kann das extrem stark sein: täglicher Themen-Scan, Alerts für Produktseiten/Repos, Zusammenfassung von neuen Paper/Release Notes, und am Ende ein Draft-Briefing. Aber genau hier gilt wieder: Proaktivität ohne Grenzen ist gefährlich. Ein guter Betrieb hat klare Regeln: Welche Quellen, welche Accounts, welche Aktionen – und was darf nur als Vorschlag kommen.

10) „Brain Swap“: Provider wechseln, Memory behalten

Ein bemerkenswerter Moment im Video ist der Umgang mit Provider-Problemen: Während der Aufnahme scheint es eine Restriktion/Änderung auf der Anthropic-Seite zu geben, wodurch Requests abgelehnt werden. VelvetShark zeigt dann das Konzept, das self-hosted Agenten stark macht: Modell/Provider wechseln (z. B. auf Gemini), während Memory und die lokale Struktur erhalten bleiben. Das ist die saubere Trennung zwischen „Denken“ (LLM) und „Erinnern“ (Memory) – und genau die Stelle, an der viele Nutzer erstmals verstehen, warum „self-hosted“ nicht nur Datenschutz ist, sondern auch Resilienz. Praktisch bedeutet das: Ein Assistant ist nicht an eine App gebunden, sondern an dein System. Wenn Provider A zickt, schaltest du auf Provider B, ohne deinen gesamten Workflow neu zu erfinden. Wichtig dabei: Der Wechsel ist kein Freifahrtschein. Provider unterscheiden sich in Kosten, Latenz, Tool-Use-Qualität, Safety-Policies – und je nachdem, welche Skills du nutzt, fühlt sich der Agent anders an. Aber als Betriebsprinzip ist der „Brain Swap“ Gold wert: Du minimierst Vendor-Lock-in auf der Schicht, die am volatilsten ist.

11) Security & Hardening: Was wirklich zählt

VelvetShark betont mehrfach, dass ClawdBot ein echter Agent ist – und damit echte Risiken trägt. Aus dem Video lassen sich die wichtigsten Hardening-Regeln destillieren: Keine unnötigen offenen Ports (Remote-Zugriff lieber über Private Networking wie Tailscale), nicht als root betreiben, Updates ernst nehmen, Tokens/Keys niemals „irgendwo“ ablegen, Skills restriktiv aktivieren, und vor allem: sensible Accounts erst verbinden, wenn das Betriebskonzept steht. Besonders wichtig ist der WhatsApp-Hinweis: Weil WhatsApp nicht so sauber „Bot vs. User“ trennt wie Telegram, sollte man dort mit dedizierter Nummer arbeiten – sonst können eingehende Nachrichten schnell zu Agent-Input werden, der nicht dafür gedacht war. Dazu kommt die Baseline, die bei Agenten immer gilt: Least Privilege (nur was gebraucht wird), Separation (dedizierte Accounts/Scopes), Approvals (für irreversible Aktionen), Audit/Logs (Nachvollziehbarkeit). Wer diese Regeln ignoriert, baut sich eine komfortable Fernbedienung – leider nicht nur für sich selbst. Wer sie umsetzt, bekommt den Produktivitätsgewinn, ohne dass der Agent zum Sicherheitsereignis wird.

Hardening-Checkliste: 10 Regeln für einen sicheren Start

  • Private Access bevorzugen: Remote-Zugriff via VPN/Zero-Trust (z. B. Tailscale), nicht per offenem Port.
  • Dedizierter User: Nicht als root betreiben, Rechte klein halten.
  • Skills minimal: Erst „Read/Research/Summarize“, dann „Write/Act“.
  • Tokens wie Bargeld: Secret-Store nutzen, rotieren, niemals in Chats/Logs posten.
  • Telegram Pairing: Allowlisting/Policies strikt, nur autorisierte Sender.
  • WhatsApp nur mit Konzept: Dedizierte Nummer, klarer Input-Scope.
  • Approvals: Mails senden, Posts, Käufe, Admin-Aktionen nur mit Bestätigung.
  • Updates: OS + Dependencies + ClawdBot regelmäßig aktualisieren.
  • Isolation: Keine privaten Daten/Browserprofile auf dem Host, wenn nicht zwingend.
  • Logs/Audit: Aktionen nachvollziehbar halten (wann, wodurch, was genau).

12) FAQ

Ist ClawdBot eher „Chat“ oder eher „digitaler Mitarbeiter“?

Die Trennlinie ist Tool-Zugriff. Ohne Skills ist es „nur“ Chat in Telegram. Mit Skills (Mail, Browser, Calendar, Automationen) wird es zu einem Agenten, der Aufgaben ausführt – also eher „Mitarbeiter“, aber nur so sicher wie dein Setup.

Warum bevorzugt das Video Telegram statt WhatsApp?

Telegram hat ein klares Bot-Modell und saubere Pairing-Mechaniken. Bei WhatsApp ist das schwieriger, weshalb dort dedizierte Nummern und striktere Input-Kontrollen wichtig werden.

Reicht ein günstiger VPS wirklich aus?

Für Gateway, Memory und viele Basis-Skills: oft ja. Die LLM-Kosten hängen jedoch am Provider (Abo/API). Der VPS ist der „always-on Host“, das Modell ist die variable „Brain-Kostenstelle“.

Was ist der häufigste Anfängerfehler?

Zu viele Rechte zu früh: Skills aktivieren, Tokens hinterlegen, Accounts verbinden, Ports öffnen – ohne Policies/Approvals/Isolation. Sicherer ist: minimal starten, Nutzen beweisen, dann gezielt erweitern.

Kann man den Provider wechseln, ohne alles neu aufzusetzen?

Das ist eines der Kernversprechen der Architektur: Memory bleibt lokal bestehen, der „Brain“ (LLM/Provider) kann getauscht werden – je nach Integration und Skill-Qualität fühlt sich der Agent dann unterschiedlich an.

13) Fazit

VelvetShark trifft mit dem Siri-Vergleich ins Schwarze: Der Reiz von ClawdBot ist nicht „noch ein Chatbot“, sondern ein always-on System mit Memory, Messenger-Nähe und Proaktivität. Genau dadurch wirkt es wie die Assistenz, die viele seit Jahren erwarten – nur eben nicht von Apple/Google, sondern aus einer Open-Source-Community. Der Preis dafür ist Verantwortung: Ein Agent mit Skills ist ein privilegierter Dienst. Wer Isolation, Policies, minimale Rechte und sichere Remote-Zugänge ernst nimmt, bekommt einen echten Produktivitätshebel. Wer es wie eine Spielzeug-App behandelt, lädt sich Risiko ein. Unterm Strich ist das Video ein sehr guter, praxisnaher Einstieg – mit der richtigen Botschaft am Ende: Security-Doku lesen und Betrieb bewusst aufsetzen, dann macht das „Siri-Versprechen“ plötzlich Sinn.

Zum Security-Guide auf drohnen.de ✅

Weitere aktuelle News-Beiträge