Screen-Recordings und kurze Video-Walkthroughs gehören mittlerweile zum Alltag, nur wanderte bisher jede einzelne Aufnahme still und heimlich auf fremde Server oft Übersee und das mag die DSGVO so gar nicht. Cap ist der Loom-Killer, auf den einige gewartet haben: quelloffen, kostenlos und selbst gehostet macht es alles, wofür man bei Loom monatlich zahlt, meistens sogar besser. Gleicher Workflow von Aufnahme zu sofort teilbarem Link, nur ohne Anbieter, Abo und Datenabfluss dazwischen. Ich habe Cap an einem Nachmittag auf meinem eigenen k3s-Cluster selbst gehostet, demselben Cluster, den ich vor ein paar Monaten von Google Cloud dorthin umgezogen habe.
Was Cap eigentlich kann
Cap ist eine native Desktop-App für Mac und Windows, die Bildschirm, Webcam oder beides aufnimmt, die Aufnahme hochlädt und sofort einen teilbaren Link liefert, derselbe Kernablauf wie bei Loom. Auch die Dinge, für die man bei Loom eigentlich zahlt, kann Cap: sofortiges Teilen ohne Export, optionale Transkription und KI-Zusammenfassungen (Cap lässt sich dafür an AssemblyAI, Groq, OpenAI oder Anthropic anbinden), dazu ein Web-Dashboard zum Verwalten der Aufnahmen. Kurz gesagt: die kostenlose Version von Loom, mit dem Unterschied, dass der komplette Stack Open Source ist und auf eigener Infrastruktur läuft, kein Preismodell, keine Limits, keine Daten bei einem Drittanbieter.
Warum selbst hosten
Zwei Gründe gaben den Ausschlag: Kosten und Datenhoheit. Jede Aufnahme, die mit der Cloud-Version entsteht, Screen-Captures, Meeting-Walkthroughs, interne Demos, liegt auf Cap’s Servern. Self-Hosting heißt: Aufnahmen verlassen nie die Infrastruktur, die ich ohnehin schon bezahle und der ich vertraue, und es gibt kein Pro-Kopf-Abo, das mit wachsender Nutzung immer teurer wird, genau der Punkt, an dem Loom irgendwann teuer wird und Cap einfach kostenlos bleibt.
Wie einfach die Umsetzung wirklich war
Das ist der Teil, der den Artikel wert ist, denn meine Annahme vorher war: Docker-Compose in Kubernetes-Manifeste zu übersetzen wird mühsam. War es nicht, aus einem konkreten Grund: Cap liefert offizielle, fertig gebaute Container-Images für beide Backend-Dienste, Web-App und Media-Server. Viele Self-Hosting-Anleitungen für andere Tools gehen davon aus, dass man das Repo klont und selbst baut. Bei Cap ist das gar nicht nötig, sobald man weiß, dass die Images existieren (ghcr.io/capsoftware/cap-web und ghcr.io/capsoftware/cap-media-server). Das spart die komplette CI-/Build-Pipeline.
Die resultierende Architektur ist entsprechend klein:
- MinIO als S3-kompatibler Objektspeicher für die eigentlichen Aufnahme-Dateien
- cap-web, die Next.js-Anwendung samt Dashboard
- media-server, ein schlanker Begleitdienst für die Medien-Pipeline
- MySQL, dafür habe ich eine bereits im Cluster laufende, gemeinsam genutzte Datenbankinstanz wiederverwendet
- Traefik + cert-manager, die im Cluster ohnehin schon Ingress und TLS für jede andere App übernehmen
Alles lief über denselben GitOps-Flow mit ArgoCD, der bereits für jede andere App im Cluster genutzt wird: neue Manifeste, ein Git-Push, ArgoCD hat automatisch synchronisiert. Kein neues Deployment-Tooling, kein Sonderfall, genau der Vorteil, den ein einheitlicher Kubernetes-Unterbau bringt.
Der eine Wermutstropfen
Ganz ohne Handarbeit ging es nicht: An der Cap-Desktop-App musste ich eine Sache manuell ändern, die “Cap Server URL” von cap.so auf meine eigene Domain umstellen. Kein Onboarding-Dialog dafür, kein Toggle, einfach ein Einstellungsfeld, das man kennen muss. Danach lief aber jede Aufnahme automatisch über die eigene Infrastruktur, ohne weiteres Skript, ohne Workaround.
Hat es sich gelohnt
Ja, und einfacher als erwartet. Die “durchwachsene Self-Hosting-Erfahrung”, von der manche frühen Berichte sprechen, scheint daher zu kommen, dass ein kompletter Build aus dem Quellcode angenommen wird. Nötig ist das nicht, wenn man von den offiziellen Images aus deployt. Kein Loom, kein Cap Cloud, kein monatliches Abo, das mit jedem neuen Teammitglied teurer wird.
Selbst ausprobieren
Cap ist Open Source im CapSoftware/Cap-Repository auf GitHub, mit einer docker-compose-Datei für ein schnelles lokales Setup und vollständiger Self-Hosting-Doku. Wer bereits einen k3s-Cluster mit ArgoCD betreibt, wie ich hier beschrieben habe, braucht davon ausgehend nicht viel mehr als die Manifeste für die fünf Bausteine oben.
Links & Ressourcen
- Cap (GitHub) - Open-Source Loom-Alternative
- ArgoCD - GitOps Continuous Delivery
- k3s - Lightweight Kubernetes
- MinIO - S3-kompatibler Objektspeicher
Kommentare