Zum Hauptinhalt springen
Capgo CLI + MCP

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.

✓ MCP-Tools für AI-Agents ✓ OTA- oder Native-Release-Checks ✓ Signierte Builds im selben Terminal
Capgo CLI

Release-Checks, geschützte Uploads und Native Builds in einer Terminal-Session.

npx @capgo/cli bundle releaseType
Animiertes Beispiel — Tabs wechseln den Command-Flow
CLI Proof

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.

5.0/5 von Entwicklerteams bewertet 9,400+ Teams Bewertungen lesen

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.

Nate van Jole CTO, Privat

Geräte-IDs bestimmten Gruppen zuzuweisen und Änderungen gezielt nur an diese Gruppen zu pushen, ist ein echter Gamechanger.

no-tone @ Webincode Entwickler, Webincode
Ehrlicher Vergleich

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.

Von Martin

Warum die Capgo CLI wichtig ist

Capgo Gründer Martin darüber, wie man Capacitor-Releases aus dem Terminal ausliefert, die Kompatibilität vor dem Push prüft und native Builds im selben Workflow behält.

Martin, Gründer, Capgo

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. 1

    Update-, Upload-, Build- und Verifizierungs-Flows initialisieren

    npx @capgo/cli@latest init
  2. 2

    Fragen, ob ein Release OTA oder nativ sein soll

    npx @capgo/cli@latest bundle releaseType com.acme.app --channel production
  3. 3

    Ein geschütztes live update mit Preview-QR hochladen

    npx @capgo/cli@latest bundle upload --channel production --fail-on-incompatible --qr-preview
  4. 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
Capgo API Keys-Seite, die Keys für GitHub Actions, Fastlane, ein Read-only-Support-Dashboard und den Capgo MCP-Server auflistet, jeweils mit Ablaufdatum

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.

Apps
Bundles
Kanäle
Kompatibilität
Native Builds
Statistiken
Doctor
Delivery-Probe

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
KI-Tools entdecken

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.

https://api.capgo.app/mcp

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.

bereit
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.

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.