Cap-go / capgo

Console to manage and distribute your live update ➡️ Get Instant updates for your App with Capgo Missing a feature? We’ll build the plugin for you 💪 Features • ☁️ Cloud / Self hosted Support: Use our Cloud to manage your app updates or yours. • 📦 Bundle Management: Download, assign to channel, rollback. • 📺 Channel Support: Use channels to manage different environments. • 🎯 Set Channel to specific device to do QA or debug one user. • 🔄 Auto Update: Automatically download and set the latest bundle for the app. • ✅ Official Appflow alternative: our Capacitor updater plugin is the official alternative to Ionic Appflow. • 🛟 Rollback: Reset the app to last working bundle if an incompatible bundle has been set. • 🔁 **Delta Updates**: Make instant updates by only downloading changed files. • 🔒 **Security**: Encrypt and sign each updates with best in class security standards. • ⚔️ **Battle-Tested**: Used in more than 3000 projects. • 📊 View your deployment statistics • 🔋 Supports Android and iOS • ⚡️ Capacitor 8/7/6/5 support • 🌐 **Open Source**: Licensed under GNU AFFERO GENERAL PUBLIC LICENSE • 🌐 **Open Source Backend**: Self install our backend in your infra Usage Capgo is deployed to production on Cloudflare workers and Supabase. Cloudflare workers take 99% of the traffic. Supabase is used for internal calls, for internal tasks such as CRON jobs that call functions. When self-hosted, installing only Supabase is sufficient. Why Cloudflare Workers + Supabase We support both deployments for practical reasons: • **Supabase** is the legacy backend and the only required piece for self-hosting. • **Cloudflare Workers** runs the same backend code (via the Hono adapter) but is much cheaper at Capgo scale. With ~50M devices, Supabase Edge Functions are cost-prohibitive because they follow AWS pricing. Cloudflare is ~10x cheaper for our traffic profile. In production, we route most traffic through Cloudflare Workers for cost and scale, while Supabase remains the reference backend and the default for self-hosted deployments. Private endpoints and trigger/CRON workloads still run on Supabase in production. Project structure (self-hosting map) If you're self-hosting, the key pieces live in a few top-level directories: • - **Primary backend for self-hosting** • - Edge functions (Deno) that power the API • - Core implementation used by both Supabase and Cloudflare • - Public API routes used by customers and apps • - Internal API routes for the console and ops tooling • - Plugin endpoints (updates, stats, channel_self, etc.) • - Database triggers and CRON functions • - Database schema and RLS policies • - Local seed data for tests/dev • - Production schema dump (reference only) • - **Optional** Cloudflare Workers deployment (prod traffic) • - Geo routing for replicas • Worker entry points and deploy config live here • - Frontend Vue 3 web console (Vite + Tailwind + DaisyUI) • - File-based routes • - Reusable UI components • - API clients and integrations • - Pinia stores • - Raw SQL helpers and maintenance scripts • - Dev/build scripts used by CI and local tooling • - Backend Vitest tests (run in parallel) • - Frontend E2E tests • - Extra documentation and guides • , - Capacitor native projects (mobile builds) Quick self-hosting path: • is enough to run the backend locally. • is the web console you point to your own backend. • is only needed if you want to run the Workers layer instead of (or in front of) Supabase. Backend endpoints (what lives where) The backend is split by responsibility to keep routes clear and access scoped: • - **Public API** exposed to customers. This is the documented API on the website for customers that want to interact with Capgo programmatically (apps, channels, bundles, devices, etc.). • - **Private API** used internally. The console (web UI) uses this heavily for admin/ops workflows. It is not publicly accessible. Some UI flows still use the public API where appropriate. • - **Plugin API** used by the plugin running inside apps: • - device update checks and bundle download flow • - upload usage stats from devices • - allow a device to opt into a channel (QA/debug) • - **Triggers & CRON** for automated backend jobs (queue consumers, scheduled tasks, DB-triggered flows). When self-hosting, you generally expose + . should stay internal and locked down. runs automatically. Production schema (prod.sql) is a schema dump of the production database. It is generated via (or ) and is meant for reference/diffing, not as a source of truth. All actual schema changes live in . Documentation https://github.com/Cap-go/capacitor-updater/wiki/Capgo-Sandbox-App • Changing Supabase Plugins All the following official plugins are already installed and pre-configured: • Action Sheet - Provides access to native Action Sheets. • App - Handles high level App state and events. • App Launcher - Allows to check if an app can be opened and open it. • Browser - Provides the ability to open an in-app browser and subscribe to browser events. • Camera - Provides the ability to take a photo with the camera or choose an existing one from the photo album. • Clipboard - Enables copy and pasting to/from the system clipboard. • Device - Exposes internal information about the device, such as the model and operating system version, along with user information such as unique ids. • Dialog - Provides methods for triggering native dialog windows for alerts, confirmations, and input prompts. • Filesystem - Provides a NodeJS-like API for working with files on the device. • Geolocation - Provides simple methods for getting and tracking the current position of the device using GPS, along with altitude, heading, and speed information if available. • Haptics - Provides physical feedback to the user through touch or vibration. • Keyboard - Provides keyboard display and visibility control, along with event tracking when the keyboard shows and hides. • Local Not…