ClawHosters
von Daniel Samer
12 Min. Lesezeit
Es war Samstagabend, kurz vor elf. Ich saß auf der Couch, Bier in der Hand, irgendeine Serie lief. Mein Handy vibrierte. Discord. "Hey Daniel, mein Bot antwortet nicht mehr. Kannst du mal gucken?"
Klar. Konnte ich. Weil ich das inzwischen im Schlaf konnte.
Ich war der inoffizielle OpenClaw-Typ in meinem Freundeskreis geworden. Der Mensch, den man anruft, wenn der KI-Assistent plötzlich aufhört zu antworten. Wenn Docker sich beschwert. Wenn die API-Keys nicht mehr stimmen. Wenn irgendein Port blockiert ist und niemand weiß warum.
Nach ein paar Monaten hatte ich die Schnauze voll. Und dann dachte ich: "Ich sollte daraus einfach eine richtige Sache machen."
Also hab ich das getan. Das Ergebnis ist ClawHosters.com. Managed OpenClaw Hosting. Diese Website hier hab ich übrigens auch mit Rails gebaut. Und das hier ist die Geschichte, wie ClawHosters entstanden ist.
Das Problem mit dem OpenClaw Setup
OpenClaw ist ein fantastisches Projekt. Über 145.000 GitHub Stars und 20.000 Forks sprechen für sich. Ein eigener KI-Assistent, den du auf deinem eigenen Server betreibst, der mit Telegram, WhatsApp, Discord und Slack funktioniert. Klingt gut. Ist auch gut.
Aber das OpenClaw Setup? Das ist eine andere Geschichte.
Ich hab OpenClaw erst bei mir selbst eingerichtet, dann bei meinem Kumpel Alex. Dann bei dessen Mitbewohner. Dann bei einem Arbeitskollegen. Dann bei der Schwester von jemand anderem. Irgendwann waren es acht Leute innerhalb von zwei Monaten. Und jedes Mal waren es dieselben Probleme.
Docker-Konflikte. Port-Forwarding. API-Keys. Firewall-Regeln. Updates, die das ganze Setup zerschießen. Jedes verdammte Mal die gleiche Scheiße.
Ich bin nicht der Einzige. Ein Entwickler hat in einem GitHub-Gist ziemlich genau das Gleiche beschrieben: Das Setup "kann schnell zum Albtraum werden, besonders wenn man nicht besonders technisch ist." Und selbst wenn du technisch bist, nervt es. Ich bin seit über zehn Jahren Entwickler, und trotzdem hab ich bei jedem Setup mindestens eine Stunde mit irgendwelchem Mist verbracht, der nicht funktionieren wollte.
Das Muster war immer gleich:
1. Jemand wollte OpenClaw ausprobieren
2. Jemand hat die offizielle Anleitung befolgt
3. Irgendetwas hat nicht geklappt
4. Jemand hat mich angerufen
Ich konnte die Probleme im Schlaf lösen. Das war nicht das Thema. Das Thema war, dass ich um elf Uhr abends am Samstag per Discord-Screenshare Config-Dateien debuggt hab, obwohl ich eigentlich meine Serie gucken wollte.
Genau diese wiederkehrenden Probleme haben mich später zur Idee für einen Managed OpenClaw Hosting Service gebracht. Einen Weg, diese technischen Hürden komplett zu eliminieren.
Der Moment, in dem es klick gemacht hat
Ich glaub, es war beim sechsten oder siebten Setup, als ich dachte: Moment mal. Ich mach bei jedem exakt das Gleiche. Gleicher Server bei Hetzner mieten. Docker installieren. Firewall konfigurieren. OpenClaw-Image pullen. Config schreiben. Testen. Sicherstellen, dass der Kram nach einem Neustart noch läuft.
Warum automatisiere ich das nicht einfach?
Ich kenne das Muster. Adam Wathan hat Tailwind CSS nicht geplant. Er hat ein CSS-Utility-Framework für ein eigenes Projekt gebaut, es öffentlich gezeigt, und die Leute haben danach gefragt. Aus einem Nebenprojekt wurde ein Multi-Millionen-Business.
Wird ClawHosters das nächste Tailwind? Vermutlich nicht. Aber das Muster ist das gleiche. Du löst ein Problem für dich selbst. Du löst es für Freunde. Irgendwann merkst du, dass jeder das gleiche Problem hat. Und dann formalisierst du die Lösung.
Das wollte ich tun.
Die technische Reise: Hetzner, Docker und viel Trial and Error
Ich bin Rails-Entwickler. Seit 2016, fast ausschließlich. Ich hab mit Rails RLTracker.pro gebaut, wo wir 2,4 Millionen Trades verarbeitet haben. Ich hab Splex.gg gebaut, das 60% aller Splinterlands-Vermietungen abgewickelt hat. Ich hab Golem Overlord gebaut, ein Blockchain-Spiel mit 20.000 täglichen Spielern.
Ich sag das nicht zum Angeben. Ich sag das, weil es erklärt, warum mein erster Gedanke war: "Ich bau das in Rails." Seit Jahren entwickle ich individuelle Webanwendungen mit diesem Framework.
Die Infrastruktur
Das Managed OpenClaw Hosting von ClawHosters läuft auf der Hetzner Cloud. Die Wahl war einfach: Hetzner ist gut, günstig und hat eine ordentliche API. Ich benutze Hetzner seit Jahren für meine eigenen Projekte.
Das grundsätzliche Konzept:
Ein Kunde klickt "Instanz erstellen". Mein System erstellt automatisch einen VPS bei Hetzner. Der Server wird aufgesetzt, OpenClaw wird deployed, und nach weniger als einer Minute ist alles fertig.
Klingt einfach. War es nicht.
Der erste Versuch: Cloud-init von Grund auf
Die erste Version hat alles von null installiert. Neuer Server, leeres Ubuntu, dann per cloud-init den ganzen Stack aufbauen: Pakete, Docker, Firewall, OpenClaw-Image. Hat funktioniert, aber ich saß da und hab zugeschaut, wie apt-get vier Minuten lang Pakete installiert hat.
Allein das Docker-Image runterladen hat ein bis zwei Minuten gefressen, je nach Bandbreite.
Vier bis fünf Minuten. Für einen Dienst, der "1-Klick-Deployment" verspricht? Vergiss es.
Der Snapshot-Ansatz: Vorher einbacken
Die Lösung war Snapshots. Ich nehme einen fertig konfigurierten Server, mache davon ein Image, und erstelle neue Instanzen aus diesem Image. Alles vorinstalliert: Docker, das OpenClaw-Image, Firewall-Regeln, fail2ban, sogar die Playwright-Browser für Web-Automatisierung.
Jetzt sieht der Ablauf so aus: Server aus Snapshot erstellen (circa 30 Sekunden), per SSH verbinden und die spezifische Konfiguration hochladen (docker-compose.yml, Umgebungsvariablen, OpenClaw-Config), Container starten, Health-Check. Fertig.
Unter einer Minute. Das war der Durchbruch für ein wirklich schnelles Managed Hosting. Keine langen Wartezeiten mehr beim OpenClaw Setup.
Die Sicherheit: Weil Paranoia manchmal berechtigt ist
Ich hab viel Zeit mit dem Sicherheitskonzept verbracht. Vielleicht zu viel. Aber als Docker-Sicherheitsforscher über 17.500 offen erreichbare, selbst gehostete Instanzen fanden, viele davon Tage nach kritischen Updates immer noch ungepatcht, war mir klar: Paranoia hat ihren Platz.
Wenn ein Kundenserver kompromittiert wird, ist das mein Problem. Also lieber zu viel Sicherheit als zu wenig.
Jeder OpenClaw Server bei ClawHosters hat iptables mit einer Default-DROP-Policy. Das bedeutet: Alles wird blockiert, was nicht explizit erlaubt ist. Erlaubt sind SSH (Port 22) und die Web-UI (Port 8080). Ausgehend blockiere ich SMTP- und IRC-Ports, damit niemand die Server zum Spam-Versand oder als Botnet-Knotenpunkt missbrauchen kann.
fail2ban sperrt nach drei fehlgeschlagenen SSH-Versuchen für eine Stunde. Rate-Limiting gegen Port-Scans. Docker-Daemon-Hardening mit no-new-privileges und eingeschränkten Dateibeschreibungen.
Klingt nach viel. Ist es auch. Aber bei managed hosting trage ich die Verantwortung. Wenn ein Kundenserver kompromittiert wird, ist das mein Problem. Also lieber zu viel Sicherheit als zu wenig.
Was dabei rauskam: ClawHosters als Managed Hosting Lösung
ClawHosters.com ist jetzt live. Managed OpenClaw Hosting auf Hetzner-Infrastruktur.
Was es bietet:
OpenClaw-Instanz in unter einer Minute
Telegram, WhatsApp, Discord, Slack
BYOK (Bring Your Own Key) für Anthropic oder OpenAI
Voller SSH- und Root-Zugang
Automatische Updates und Wartung
Das ist KI Hosting, wie es sein sollte: Einfach, schnell, ohne technische Kopfschmerzen. Automatische Wartung und Updates inklusive.
Was es nicht bietet:
Keine Konkurrenz zum Selbst-Hosten. Wenn du Spaß daran hast, deinen eigenen VPS zu verwalten, mach das. Kein Problem.
Keine Black Box. Du hast Root-Zugang. Du besitzt deine Daten.
Der letzte Punkt ist mir wichtig. Ich hab bewusst keinen geschlossenen Service gebaut. Jeder Kunde hat vollen Zugang zu seinem Server. Wenn du von ClawHosters weg willst, nimmst du deine Daten und gehst. Fertig.
Was ich unterschätzt habe
Ich bin ehrlich: Ich hab unterschätzt, wie viel Arbeit neben der eigentlichen Technik anfällt.
Support ist eine eigene Disziplin
Kunden haben Fragen. Viele Fragen. Und nicht immer die gleichen. Jemand will wissen, wie man einen Telegram-Bot mit dem Gateway verbindet. Jemand anderes hat ein Problem mit dem API-Key-Format. Wieder jemand fragt, ob WhatsApp funktioniert, wenn der Gateway neu startet.
Ich hab das am Anfang unterschätzt. Ich dachte: "Die Leute sind Techies, die kriegen das hin." Manche schon. Manche nicht. Und das ist okay. Dafür gibt es den Service ja.
Die Deployment-Pipeline hat mich drei Versuche gekostet
Der erste Anlauf war zu langsam (cloud-init von null, wie beschrieben). Der zweite Anlauf hatte ein subtiles Problem: Mein Hintergrundjob-System (Sidekiq) hat nach einem Deployment noch alten Code im Speicher gehabt. Das bedeutete: Ich hab neuen Code deployed, der eine Config-Datei hochladen sollte. Aber der Deployment-Job lief mit dem alten Code, der diese Funktion noch nicht hatte.
Das Ergebnis? Instanzen ohne die richtige Config. Kunden, die eine "Pairing Required"-Meldung bekamen, obwohl alles hätte funktionieren müssen.
Ich hab drei Stunden gebraucht, um das zu verstehen. Drei Stunden, in denen ich dachte: "Das Deployment ist durch. Was zur Hölle läuft da schief?" Bis mir klarwurde: Der Job ist durch. Mit dem alten Code.
Die Lösung: Worker nach jedem Deployment automatisch neu starten. Klingt offensichtlich im Nachhinein. War es im Moment nicht.
Pricing ist Psychologie, nicht Mathematik
Ich wollte fair preisen. Die Hetzner-Kosten für die Server sind bekannt. Darauf kommt meine Arbeit: Wartung, Updates, Support, Infrastruktur. Ich hab mir die Preise der Konkurrenz angeschaut. Und ich hab einen Preis gewählt, mit dem ich mich wohlfühle.
Kein Betrag, bei dem ich das Gefühl hab, Leute über den Tisch zu ziehen. Aber auch kein Betrag, bei dem ich mir nach einem halben Jahr sage: "Das lohnt sich nicht."
Die Details stehen auf clawhosters.com.
Warum nicht einfach selbst hosten? Wann Managed Hosting besser ist
Berechtigte Frage. Ich hab kein Problem mit Leuten, die selbst hosten. Ich hab das selbst wochenlang gemacht. Wenn du die OpenClaw Installation genießt, wenn du gerne an VPS Management arbeitest, wenn du die Kontrolle über jeden Aspekt willst: Mach das.
ClawHosters ist für die anderen. Für die Leute, die OpenClaw wollen, aber keinen Bock haben, sich um Docker, Updates, Firewall und Monitoring zu kümmern.
Ich kann bei meinem Auto den Ölwechsel selber machen. Mach ich aber nicht. Nicht weil ich es nicht kann, sondern weil ich lieber Code schreibe als unter einem VW Golf zu liegen. Managed Hosting ist die gleiche Logik.
DigitalOcean hat es gut auf den Punkt gebracht: Jede Stunde, die du mit Server-Verwaltung verbringst, ist eine Stunde, die du nicht mit deinem eigentlichen Projekt verbringen kannst.
Für mich persönlich: Ich bin Entwickler. Ich baue lieber Features als Server zu administrieren. ClawHosters erlaubt mir, einen Service anzubieten, der genau das für andere tut.
Was als Nächstes kommt
Ich arbeite noch an einigen Sachen. Es gibt Features, die ich bauen will, aber noch nicht fertig sind. Verbesserungen am Dashboard. Mehr Automatisierung. Bessere Dokumentation.
Werde ich genauer, wenn es soweit ist.
Im Moment bin ich an dem Punkt, an dem das Fundament steht und die Sache funktioniert. Kunden können sich anmelden, eine Instanz erstellen, und in weniger als einer Minute mit ihrem eigenen KI-Assistenten loslegen. Das war das Ziel. Das ist erreicht.
Der Rest kommt nach und nach.
Ehrliches Fazit
Ich hab ClawHosters nicht gebaut, weil ich einen großen Businessplan hatte. Ich hab es gebaut, weil ich ein Problem für mich und meine Freunde gelöst hab und irgendwann gemerkt hab: Das Problem haben viele.
Die Deployment-Pipeline hat mich eine Weile gekostet. Aber jetzt bin ich an einem Punkt, an dem ich mich nicht schäme, es zu teilen.
Wenn du OpenClaw als Managed Service nutzen willst, ohne dich um die Infrastruktur zu kümmern: clawhosters.com.
Wenn du lieber selbst hostest: Respekt. Viel Erfolg.
Und wenn dein Bot Samstagabend um elf aufhört zu antworten, weißt du jetzt, wem du schreiben kannst.
