ClawdBot/Moltbot in 2 Minuten: AWS Free Tier Setup, Telegram & Exa – Video-Guide 2026

ClawdBot/Moltbot: Kostenlos in der Cloud hosten (AWS Free Tier) – Speedrun-Setup, Telegram & Exa-Websuche (Video-Guide, Januar 2026)

Stand: 28.01.2026

Man kann über KI-Agenten lange philosophieren – oder man macht’s wie „Tech Friend AJ“ und zeigt in wenigen Minuten die Praxis: frischer AWS-Server, One-Line-Install, Onboarding, Telegram-Pairing, fertig. Genau dieser „Setup ohne Friktion“-Ansatz ist einer der Gründe, warum ClawdBot (im Umfeld häufig auch als Moltbot bezeichnet) 2026 so viral wirkt: Es ist nicht nur „Chat“, sondern ein Agent, der – je nach Skills und Berechtigungen – echte Aktionen ausführen kann und über Kanäle wie Telegram/WhatsApp/Discord steuerbar ist. AJ setzt dabei auf ein starkes Narrativ: 24/7 Hosting für 0 € (AWS Free Tier) und ein Setup, das auch ohne SSH-Key im Browser funktioniert. Das ist bequem – und genau deshalb muss man die Kehrseite mitdenken: Ein Agent mit Systemzugriff ist keine Spielzeug-App, sondern im besten Fall produktive Automationsmaschine – im schlechtesten Fall eine freundliche Fernbedienung für deine Accounts, wenn Zugriff, Ports, Keys oder Skills falsch konfiguriert sind.


Direkt zum Inhaltsverzeichnis ✅

Dieser Beitrag fasst das Video strukturiert zusammen (AWS EC2, Browser-SSH, One-Liner, API-Key/Model, „Hatching“ der Identität, Telegram-Pairing, Exa-Websuche als Skill) und ergänzt das Wichtigste, das in Speedrun-Tutorials oft fehlt: Hardening, Account-Trennung und Risiko-Stopper. Der ausführliche Hintergrund-Guide zur Einordnung (Features, Risiken, Betrieb) ist hier zu finden: Moltbot/ClawdBot: Features, Risiken & Security-Guide.

Video-Quickfacts (Tech Friend AJ)

  • Titel: “Clawdbot in Less Than 2 Minutes (FREE 24/7 HOSTING)”
  • Veröffentlichung: 24.01.2026
  • Views (Stand aus Video-Infos): 82.002
  • Hook: Speedrun vom frischen AWS-Server bis zum Telegram-Agenten
  • Key-Feature: One-Line-Install + Onboarding + Skills/Channels
  • Bonus: Exa-Websuche als Skill (AJ zeigt „advanced browsing“ ohne klassischen API-Key-Fokus)

Das Wichtigste aus dem Speedrun auf einen Blick

  • Hosting-Route: AWS Free Tier → EC2-Instanz → Browser-SSH → One-Liner → Onboarding
  • Agent-Kern: Systemzugriff + Skills/Plugins + Messenger-Steuerung (hier: Telegram)
  • „Hatching“: Identität/Name/Zweck/Zeitzone/Vibe festlegen (AJ nennt das „Soul/Identity“)
  • Web-Suche: Exa als Skill, um Browsing/Deep Search direkt als Fähigkeit zu ergänzen
  • Wichtigster Sicherheits-Satz: Onboarding bestätigt ausdrücklich, dass das Setup riskant sein kann (Keys, Mail, Systemrechte)

1) Worum geht’s im Video?

AJ liefert ein klassisches „Speedrun“-Tutorial: nicht diskutieren, sondern in Minuten lauffähig werden. Sein Flow ist klar: Er startet mit der These „ClawdBot ist super leicht aufzusetzen – lokal oder in der Cloud“, betont Systemzugriff, Skills/Plugins und Messaging-Channels (WhatsApp/Discord/Telegram). Dann geht er direkt zu AWS: EC2-Instanz starten, per Browser verbinden, den One-Liner ausführen, Onboarding durchklicken, Token/Provider/Modell wählen, danach Telegram pairen und als erstes „Power-Up“ eine Websuche-Fähigkeit (Exa) hinzufügen. Der Reiz ist offensichtlich: Wer den Agenten in die Cloud verlegt, bekommt Always-on ohne „Mac mini am Schreibtisch“. Genau deshalb ist der Beitrag hier bewusst zweigleisig: Erst die Schritte (wie im Video), dann das, was man für den sicheren Betrieb braucht, bevor aus „gratis“ ein teures Sicherheitsproblem wird.

Zum Hauptartikel: Moltbot (ClawdBot) – Features, Risiken & Security-Guide

Wer die komplette Einordnung sucht (Rebrand von ClawdBot zu Moltbot, echte Agent-Fähigkeiten, Praxis-Use-Cases und vor allem die Security-Fallen inkl. Hardening-Checkliste), findet alle Details im ausführlichen Hauptartikel.

  • Was Moltbot wirklich ist: Local-first Agent statt „nur Chat“
  • Warum es viral ging: Always-on + Skills + Messenger-Steuerung
  • Wichtigster Teil: Risiken (Berechtigungen, Exposures, Secrets) & Schutzmaßnahmen
  • Praxis: Setups, Kosten, sinnvolle Use-Cases & klare No-Gos

Hauptartikel öffnen ✅

2) AWS Free Tier: Was AJ zeigt (und was man realistisch beachten sollte)

Im Video ist AWS die Abkürzung zum 24/7-Agenten: AJ öffnet EC2, startet eine Instanz (Ubuntu), wählt „free“ bzw. Free-Tier-nahe Optionen, und behauptet sinngemäß: Solange man keine zusätzlichen Ressourcen deployt, bleibt es kostenfrei. Für die Praxis ist die saubere Einordnung wichtig: Free Tier ist kein „für immer kostenlos“-Versprechen, sondern an Bedingungen/Zeiträume und die Nutzung bestimmter Ressourcen gebunden. Wer es wirklich kostenstabil will, sollte zwei Dinge mitnehmen: (1) Monitoring/Alarm für Kosten (Budget/Alerts), (2) eine klare Regel „keine Zusatzdienste aus Versehen aktivieren“ (Storage, Traffic, zusätzliche Instanzen). Der eigentliche Mehrwert dieser Route ist trotzdem stark: Trennung. Statt den Agenten auf dem eigenen Hauptrechner laufen zu lassen, packt man ihn in eine isolierte Umgebung. Diese Isolation ist – bei einem Agenten mit Systemrechten – nicht Luxus, sondern das Minimum an Vernunft.

Hosting-Option Vorteil Nachteil Empfehlung
AWS/VPS (Cloud) Always-on, gut isolierbar, von überall erreichbar Exponierungsrisiko, Keys/Ports/Firewall müssen sitzen Stark, wenn Hardening strikt umgesetzt wird
Separates Gerät (z. B. Mini-PC) Volle Kontrolle, lokal, kein Cloud-Traffic nötig Hardwarekosten, Wartung/Updates/Netzwerk Sehr gut für „Home-Lab“ mit sauberer Trennung
Hauptrechner Am bequemsten Maximaler Schadenradius bei Fehlern Meist No-Go bei „full system access“-Agenten

3) Browser-SSH: Schnell – aber nicht automatisch „sicher“

AJ nutzt den AWS-internen Browser-Zugriff (Connect → Browser-SSH) und spart sich damit im Tutorial viel Reibung. Das ist für Einsteiger praktisch, aber der entscheidende Punkt ist: Der Zugang ist Teil deiner Sicherheitsgrenze. Sobald jemand Zugriff auf dein AWS-Konto bekommt (schwaches Passwort, keine MFA, kompromittierter Rechner), ist der „Browser-SSH“-Weg ein direkter Hebel zur Instanz. Für einen Agenten-Host ist deshalb eine Minimal-Policy sinnvoll: MFA aktiv, Zugang auf das Nötigste beschränken, und die Instanz selbst so konfigurieren, dass sie nicht „nackt“ im Netz steht. Der Speedrun zeigt den Weg, aber die Verantwortung bleibt: Wer Cloud nutzt, muss Cloud-Disziplin mitbringen – sonst ist „Always-on“ eben auch „Always angreifbar“.

4) One-Line-Install & Onboarding: Der „Frictionless“-Moment

Der Kern des Videos ist die Ein-Zeilen-Installation von der Projektseite (AJ verweist auf claw.bot). Einmal ausführen, und man landet direkt im Onboarding. Wichtig ist, was AJ nebenbei richtig betont: Man muss bestätigen, dass das Setup riskant sein kann – besonders, wenn man dem Agenten Zugriff auf Schlüssel, Mail, Dateien oder andere sensitive Bereiche gibt. Genau hier entscheidet sich, ob man „nur“ einen cleveren Assistenten baut oder eine privilegierte Automationsmaschine mit großem Schadenradius. Der bessere Mindset für diesen Schritt ist: Onboarding = Rechtevergabe. Nicht „weiter, weiter, fertig“, sondern bewusst: Welche Skills wirklich nötig sind, welche Channels man wirklich koppeln muss und wo man strikt „Approval“ verlangt.

5) API-Key & Modellwahl: Was im Speedrun wirklich entscheidet

AJ geht „Token-Paste“ und wählt als Beispiel ein Top-Modell (im Video: „Opus 45 latest“). Der praktische Takeaway ist weniger „welches Modell“, sondern wo die Keys landen und wie man sie behandelt. Für einen Agenten-Host gilt: Keys sind keine „Setup-Notiz“, sondern Produktivzugang. Wenn der Server kompromittiert wird, sind API-Keys oft das Erste, was abfließt – und dann wird „kostenlos“ schnell „Kostenexplosion“, wenn ein Angreifer Anfragen in deinem Namen feuert. Deshalb gehört zur Modellwahl immer ein Mini-Prozess: Keys als Secrets verwalten, Rotation einplanen, und möglichst Scope/Limit nutzen, falls Anbieter das erlauben. Kurz: Das Modell steuert die Qualität; die Key-Hygiene steuert, ob du nachts ruhig schläfst.

6) „Hatching“: Identität, Zweck, Zeitzone, Tonalität

Eines der spannendsten Details im Speedrun ist „Hatching“ – AJ beschreibt das als Moment, in dem man dem Bot eine Identität gibt: Name, Beziehung („du bist X zu mir“), Zweck, vielleicht eine kurze Beschreibung der eigenen Rolle, dazu Zeitzone und „Vibe“. Das klingt spielerisch, ist aber funktional: Ein Agent, der über Messaging bedient wird, profitiert enorm von klaren Rollen, weil er sonst zwischen „Assistent“, „Dev“, „Researcher“, „Sekretariat“ und „Ops“ hin- und herspringt. Wer Hatching sinnvoll macht, baut Leitplanken: Was darf der Agent tun, was nicht? Wie kommuniziert er? Welche Outputs sind erwünscht (z. B. kurze Zusammenfassung vs. ausführliche Analyse)? Gerade im Cloud-Setup hilft eine gute Identitätsdefinition, weil man den Agenten weniger „trial and error“ trainiert – und damit weniger riskante Aktionen provoziert.

7) Telegram-Pairing: Remote-Steuerung in der Praxis

AJ pairt den Agenten mit Telegram über einen Code/Pairing-Schritt. Das ist der Moment, in dem das System vom „Serverdienst“ zum „immer verfügbaren Mitarbeiter“ wird: Nachricht schreiben, Aufgabe auslösen, Ergebnis zurückbekommen. Gleichzeitig ist Telegram (wie jeder Messaging-Kanal) ein zusätzlicher Angriffsvektor: Wenn jemand dein Telegram-Konto übernimmt, übernimmt er indirekt deine Agenten-Steuerung. Deshalb ist die beste Praxis simpel: dedizierter Telegram-Account nur für den Agenten, 2FA aktiv, und im Agenten selbst strikte Regeln: keine irreversiblen Aktionen ohne Bestätigung, keine sensiblen Daten im Klartext zurück in den Chat. Messaging ist genial – aber nur, wenn es nicht der „Schlüsselbund“ wird, den man aus Bequemlichkeit überall rumliegen lässt.

8) Exa-Websuche als Skill: Warum das sofort nützlich ist

AJ ergänzt als erstes Skill-Modul die Exa-Websuche (er beschreibt „advanced web search/deep search“ als gebündelte Fähigkeit). Das ist in der Praxis ein sinnvoller „First Skill“, weil es den Agenten sofort aus dem „lokalen Insel“-Modus holt: Er kann Dinge verifizieren, Quellen sammeln, Preise/Infos prüfen, Links zusammenstellen. Aber auch hier gilt: Web-Zugriff plus Agent-Toolchain kann ungewollte Ergebnisse erzeugen, wenn keine Regeln existieren. Gute Leitplanke: Websuche ja, aber Aktionen (Downloads, Logins, Formulare, Käufe) nur nach ausdrücklicher Bestätigung. So wird „Browsing“ zum Mehrwert, ohne dass der Agent im Hintergrund Dinge anfasst, die man später bereut.

9) Hardening-Checkliste: Cloud-Agent ohne „Offen im Internet“-Katastrophe

Hardening in 90 Sekunden: Cloud-Setup, das nicht nach „YOLO“ aussieht

  • Keine offene Admin-UI: Wenn eine Weboberfläche existiert, dann nicht frei erreichbar; Zugriff nur über VPN/Zero-Trust/Tunnel.
  • Security Group minimal: Nur das Nötigste freigeben; keine „0.0.0.0/0“-Experimente aus Bequemlichkeit.
  • AWS-Account absichern: MFA aktivieren, starke Passwörter, Zugriffe begrenzen.
  • Agent isolieren: Dedizierte Instanz nur für den Agenten; keine privaten Daten, keine Primär-Accounts.
  • Dedizierte Accounts: Telegram/Mail/Tools separat für den Agenten – nicht „dein Hauptkonto“.
  • Secrets professionell: Keys nicht als lose Textfiles; regelmäßige Rotation einplanen.
  • Approval-Pflicht: Für Senden/Posten/Kaufen/Ändern immer explizite Bestätigung verlangen.
  • Logging/Audit: Protokollieren, was wann wodurch ausgelöst wurde; so findet man Fehler und Missbrauch schneller.
  • Skills sparsam: Erst minimal starten, dann gezielt erweitern; Skill-Marktplätze sind Supply-Chain-Risiko.

Die Faustregel ist simpel: Ein Cloud-Agent ist kein „Bot“, sondern ein privilegierter Dienst. Wer ihn so betreibt (Isolation, minimale Öffnungen, klare Approvals), bekommt den Always-on-Vorteil ohne die Horrorstory. Wer dagegen Ports aufreißt, Keys verteilt und jeden Skill aktiviert, baut sich die bequemste Angriffsfläche – und merkt es oft erst, wenn etwas schiefgelaufen ist.

10) FAQ

Ist „kostenlos 24/7“ realistisch?

Im Speedrun wird AWS Free Tier als „kostenlos“ dargestellt. In der Praxis hängt das an Bedingungen und daran, ob zusätzliche Ressourcen (Traffic, Storage, weitere Dienste) aktiviert werden. Wer stabil kostenfrei bleiben will, braucht Kosten-Alerts und eine sehr disziplinierte Ressourcen-Nutzung.

Warum ist Cloud-Hosting oft sinnvoller als der Hauptrechner?

Weil Trennung Risiko reduziert: Keine privaten Dateien, keine Browser-Sessions, keine Primär-Accounts. Ein Agent mit Systemzugriff sollte möglichst wenig „zu verlieren“ haben – Isolation ist die einfachste Form davon.

Was ist der gefährlichste Anfängerfehler beim Cloud-Setup?

Irgendwas „kurz fürs Testing“ ins Internet hängen und es dann so lassen: offene Admin-UIs, zu breite Firewall-Regeln, schwache Accounts, unrotierte Keys. Speedrun-Tempo darf nie Hardening ersetzen.

Welche Skills sind ein sinnvoller Start?

Websuche/Browsing (wie im Video) ist oft der beste erste Skill, weil er Nutzen bringt, ohne sofort in deine Accounts zu greifen. Mail, Kalender, GitHub oder Terminal-Aktionen sollten erst kommen, wenn Approvals, Secrets und Logging sauber stehen.

11) Fazit

AJs Speedrun zeigt, warum ClawdBot/Moltbot 2026 so schnell „klickt“: In wenigen Minuten wird aus „Hype“ ein realer, always-on Agent, der über Telegram steuerbar ist – und mit Skills wie Exa sofort nützliche Aufgaben erledigen kann. Genau das ist aber auch die Kernwarnung: Wer Systemzugriff, Keys und Channels kombiniert, muss wie ein Betreiber denken. Mit Isolation, minimalen Öffnungen, dedizierten Accounts, Approval-Pflicht und sauberem Secrets-Handling wird aus dem Cloud-Agenten eine starke Produktivitätsmaschine. Ohne diese Basics wird aus „FREE 24/7 HOSTING“ sehr schnell „24/7 Risiko“.

Weitere aktuelle News-Beiträge