Das Setup dauerte weniger als einen Tag. Dank Channel-basierten Rollouts kann ich auf meinem eigenen Gerät testen, bevor etwas bei Production-Nutzern ankommt.
Ein CLI + MCP für alles
Ein Tool für Live Updates, Native Builds, Kompatibilitätschecks, Device Runs und KI-gestützte Capgo-Automatisierung über MCP.
Release-Checks, geschützte Uploads und Native Builds in einer Terminal-Session.
Release-Workflows, denen Teams vom Terminal bis in die Produktion vertrauen
Kurze Stimmen von Teams, die Capgo für Capacitor-Updates, Native Builds und Release-Steuerung nutzen.
Geräte-IDs bestimmten Gruppen zuzuweisen und Änderungen gezielt nur an diese Gruppen zu pushen, ist ein echter Gamechanger.
Capgo CLI vs. die Alternativen.
Gleiche Release-Arbeit. Andere Automatisierung.
| Capgo CLI | DIY / manuell Skripte, Fastlane und Dashboard-Klicks | Wettbewerber-Cloud | |
|---|---|---|---|
| CLI veröffentlichen | Ein CLI. OTA-Uploads, Native Builds, Channels, Kompatibilität, Device-Runs und MCP aus einem Terminal. | Getrennte Skripte, curl-Jobs, Fastlane-Lanes und einzelne API-Aufrufe, die du selbst pflegst. | Kein First-Class-CLI. Releases bleiben im Dashboard oder in Git-getriggerten Flows. |
| KI-Agent-Automatisierung | Integriertes MCP. Apps, Bundles, Channels, Builds, Stats und Diagnosen für Codex, Cursor, Claude Code und andere Agenten bereitstellen. | Nichts, außer du baust und pflegst eigene Tools. | Kein MCP-Server. Agenten können keine Releases für dich steuern. |
| Entscheidung OTA vs. Native | Expliziter Befehl. bundle releaseType sagt dir, ob OTA sicher ist oder vor dem Release ein Native Build nötig ist. | Manuelle Prüfung von Native-Diffs und Erfahrungswissen. | Das Dashboard gibt bestenfalls Hinweise. Unter Zeitdruck liegt man schnell falsch. |
| Abgesicherter OTA-Upload | Aus der CI. bundle upload mit Compatibility Gates, Delta-Support, Verschlüsselung und QR-Preview-Links. | Manueller Zip-Upload oder eigene API Skripte mit selbst geschriebenen Checks. | Portal-Upload oder Git-Hook. Begrenzter Preflight vom Terminal aus. |
| Native Build Requests | Im selben Terminal. build request mit Output-Records, QR-Links und Logs, die zurück in deine Shell gestreamt werden. | Xcode, Android Studio oder Fastlane auf einem Mac öffnen, den du selbst betreust. | Push nach Git oder Klick im Dashboard. Kein skriptbarer Build-Record für CI. |
| CI-Integration | Skriptbare Ausgabe. JSON-Build-Records, Exit-Codes und QR-Artefakte, anhand derer deine Pipeline Gates definieren kann. | Du verknüpfst jeden Schritt, jedes Secret und jeden Artifact-Pfad selbst. | Webhooks an einigen Stellen. Die meisten Teams koordinieren Releases aber noch manuell. |
| Kompatibilitätsprüfungen | Vor dem Upload. CLI scannt native Dependencies und bricht frühzeitig ab, wenn OTA unsicher wäre. | Keine Guardrails, außer du baust sie selbst. | Basis-Bundle-Validierung. Native Drift wird leicht übersehen. |
| Erst testen, dann zahlen | Ja. 14 Tage unbegrenzt kostenlos testen. Keine Kreditkarte nötig. | Günstig, bis man die Stunden zählt, um Skripte am Leben zu halten. | Stufenpläne. Testphasen variieren je nach Anbieter. |
Der Vergleich spiegelt typische DIY-/manuelle Setups und öffentliche Cloud-Doku von Wettbewerbern wider.
Befehlsablauf
Vom Setup bis zum passenden Release-Typ
Capgo CLI Befehle machen den wichtigen Release-Fork explizit: live update bei Änderungen am Web-Layer, Native Build, wenn die App-Binary aktualisiert werden muss.
OTA-Pfad
Nutze Compatibility Gates und Preview-QR-Links, wenn das Web-Bundle sicher aktualisiert werden kann.
Native-Pfad
Fordere einen signierten Build an, wenn sich Dependencies, Permissions oder native code geändert haben.
- 1
Update-, Upload-, Build- und Verifizierungs-Flows initialisieren
npx @capgo/cli@latest init - 2
Fragen, ob ein Release OTA oder nativ sein soll
npx @capgo/cli@latest bundle releaseType com.acme.app --channel production - 3
Ein geschütztes live update mit Preview-QR hochladen
npx @capgo/cli@latest bundle upload --channel production --fail-on-incompatible --qr-preview - 4
Native Build anfordern und Output für CI oder PRs speichern
npx @capgo/cli@latest build request com.acme.app --platform ios --build-mode release --output-upload --output-record .capgo/build.json
Automatisierung
Scoped Keys rein, Release-Events raus
Gib CI und Agenten einen Key, der nur seine Aufgabe erledigen kann, und pushe jede Bundle- und Channel-Änderung an die Tools, die dein Team schon im Blick hat.
Scoped Keys für CI, Skripte und KI-Agenten
Erstelle Keys, die auf eine Organisation oder App beschränkt sind – mit Upload-, Read- oder Write-Modus und Ablaufdatum. Keys werden gehasht gespeichert und nie wieder im Klartext angezeigt.
- Nur-Upload-Keys für CI-Pipelines
- Ablaufdatum für jeden Key
- Gehashte Speicherung, wenn deine Org es verlangt
Sende Release-Events an Slack, Datadog oder deinen eigenen Service
Abonniere Endpoints für Bundle-, Channel-, Member- und Org-Änderungen und prüfe jede Zustellung inklusive Status und Response.
- Wähle die Events für jeden Endpoint
- Delivery-Log mit Response-Codes und Retries
- Sende ein Test-Event, bevor du live gehst
Native Builds und MCP
Lass CLI die Release-Arbeit übernehmen, die deine App wirklich braucht
Wenn die Kompatibilität sagt, dass die Änderung OTA-safe ist, shippe ein abgesichertes live update. Wenn sich native code, Permissions oder Dependencies geändert haben, fordere einen Native Build an und halte den Output für CI, PRs und Reviewer sichtbar.
Frag dann deinen Agenten
- Lade diesen Build in die Production hoch und brich ab, falls er inkompatibel ist
- Fordere einen iOS Release Build an und speichere den Output-Datensatz
- Führe Capgo doctor aus und behebe die gefundenen Probleme
Füge Capgo Agent Skills hinzu, damit dein Agent jeden Workflow kennt:
npx skills add Cap-go/capgo-skills MCP installieren
Installiere Capgo CLI MCP
Registriere den CLI-Server in Codex, Cursor, Claude Code, Windsurf, VS Code, Zed oder Gemini CLI.
npx install-mcp 'npx @capgo/cli@latest mcp' --client codex
Ersetze codex mit dem Client, den dein Team nutzt.
Gehostetes MCP
Nutze Capgo direkt in Claude, ChatGPT oder Cursor
Nichts zu installieren. Kopiere die URL in einen beliebigen Remote-MCP-Client, melde dich per OAuth an und verwalte Apps, Channels, Rollouts, Geräte und Builds direkt im Chat.
Uploads und Native-Build-Anfragen laufen weiterhin über das oben genannte CLI MCP. Hosted MCP Setup Guide lesen
Build-Protokoll
iOS-Release-Build
Gespeicherte Ausgabe für CI, PR-Checks und Mobile-Review.
- Plattform
- iOS
- Modus
- Release
- Ausgabe
- IPA und Installations-QR
- Datensatz
- .capgo/build.json
npx @capgo/cli@latest build request com.acme.app --platform ios --output-upload --output-record .capgo/build.json Der Status ist sichtbar, bevor Release Notes gepostet werden.
Der QR-Code bleibt zur Gerätevalidierung verfügbar.
Fehler können die CI stoppen, bevor ein riskantes Release live geht.
Mit Capacitor gebaute Apps
Capacitor Apps benötigen Release-Tools, die native Grenzen respektieren.
Große Capacitor Apps mischen Web-Änderungen mit nativen Abhängigkeiten. Capgo CLI hält diese Grenze sichtbar, bevor ein Production-Release live geht.
Die gezeigten Apps stammen aus einem öffentlichen Store-App-Datensatz, der auf der gesamten Website verwendet wird.
WETTER
Windy.com – Wettervorhersage
TOOLS
Meine Orange
TOOLS
Mein Vodafone
Nutze CLI noch heute
Integriere Capgo in deine Release-Scripts, ohne auf eine Dashboard-Session warten zu müssen.
Starte mit der Doku zu CLI und binde dann Kompatibilitätsprüfungen, Bundle-Uploads, Native Builds oder MCP direkt in euren Workflow ein.