Profile
Back to NewsBack
GitHub Trending 13 min
Reader Mode
Cap-go/capgo.app: Console, Backend and CLI to manage Capgo Instant update and Native build for Capacitor apps

Cap-go/capgo.app: Console, Backend and CLI to manage Capgo Instant update and Native build for Capacitor apps

14 hours ago
GitHub Trending

Console to manage and distribute your live update

Capgo - Instant updates for capacitor

Bugs</a> Security Rating</a> Maintainability Rating</a> Code Smells</a> Lines of Code</a> Technical Debt</a> Reliability Rating</a> Duplicated Lines (%)</a> Vulnerabilities</a> CodSpeed</a> Known Vulnerabilities</a> !GitHub license Bump version</a> Build source code and send to Capgo</a> semantic-release Commitizen friendly



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. Capgo cloud console and current CLI calls go to the Cloudflare API hosts (VITE_API_HOST / hostApi). Capgo cloud still publishes a small Supabase function allowlist for Postgres pg_net (triggers) and for legacy CLI compatibility via /functions/v1 through 2026-10-28. Self-hosted deployments keep using /functions/v1. Plugin hot paths and other unused Capgo cloud endpoints are not published on Supabase.

Project structure (self-hosting map)

If you're self-hosting, the key pieces live in a few top-level directories:

  • supabase/ - Primary backend for self-hosting
- supabase/functions/ - Edge functions (Deno) that power the API - _backend/ - Core implementation used by both Supabase and Cloudflare - public/ - Public API routes used by customers and apps - private/ - Internal API routes for the console and ops tooling - plugins/ - Plugin endpoints (updates, stats, channel_self, etc.) - triggers/ - Database triggers and CRON functions - supabase/migrations/ - Database schema and RLS policies - supabase/seed.sql - Local seed data for tests/dev
  • supabase/schemas/prod.sql - Production schema dump (reference only)
  • cloudflare_workers/ - Optional Cloudflare Workers deployment (prod traffic)
- cloudflare_workers/snippet/ - Geo routing for replicas - Worker entry points and deploy config live here
  • src/ - Frontend Vue 3 web console (Vite + Tailwind + DaisyUI)
- src/pages/ - File-based routes - src/components/ - Reusable UI components - src/services/ - API clients and integrations - src/stores/ - Pinia stores
  • sql/ - Raw SQL helpers and maintenance scripts
  • scripts/ - Dev/build scripts used by CI and local tooling
  • tests/ - Backend Vitest tests (run in parallel)
  • playwright/ - Frontend E2E tests
  • docs/ - Extra documentation and guides
  • android/, ios/ - Capacitor native projects (mobile builds)
Quick self-hosting path:
  1. supabase/ is enough to run the backend locally.
  2. src/ is the web console you point to your own backend.
  3. cloudflare_workers/ 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:

  • supabase/functions/_backend/public/ - 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.).
  • supabase/functions/_backend/private/ - 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.
  • supabase/functions/_backend/plugin_runtime/ - Plugin API used by the
@capgo/capacitor-updater plugin running inside apps: - plugins/updates - device update checks and bundle download flow - plugins/stats - upload usage stats from devices - plugins/channel_self - allow a device to opt into a channel (QA/debug)
  • supabase/functions/_backend/triggers/ - Triggers & CRON for automated
backend jobs (queue consumers, scheduled tasks, DB-triggered flows).

When self-hosting, you generally expose public + plugin_runtime (via the plugin worker / Deno updates · stats · channel_self entries). private should stay internal and locked down. triggers runs automatically.

Production schema (prod.sql)

supabase/schemas/prod.sql is a schema dump of the production database. It is generated via bun run schemas (or bun run schemas:local) and is meant for reference/diffing, not as a source of truth. All actual schema changes live in supabase/migrations/.

Documentation

https://github.com/Cap-go/capacitor-updater/wiki/Capgo-Sandbox-App

Plugins

All the following official plugins are already installed and pre-configured:

Provides access to native Action Sheets. high level App state and events. Allows to check if an app can be opened and open it. Provides the ability to open an in-app browser and subscribe to browser events. Provides the ability to take a photo with the camera or choose an existing one from the photo album. Enables copy and pasting to/from the system clipboard. Exposes internal information about the device, such as the model and operating system version, along with user information such as unique ids. Provides methods for triggering native dialog windows for alerts, confirmations, and input prompts. Provides a NodeJS-like API for working with files on the device. Provides simple methods for getting and tracking the current position of the device using GPS, along with altitude, heading, and speed information if available. Provides physical feedback to the user through touch or vibration. Provides keyboard display and visibility control, along with event tracking when the keyboard shows and hides. Provides a way to schedule device notifications locally (i.e. without a server sending push notifications). Tracks accelerometer and device orientation (compass heading, etc.). Provides network and connectivity information. Provides access to native push notifications. Provides access to TalkBack/VoiceOver/etc. and Provides simple text-to-speech capabilities for visual accessibility. Provides methods for sharing content in any sharing-enabled apps the user may have installed. Provides methods for showing or hiding a Splash image. Provides methods for configuring the style of the Status Bar, along with showing or hiding it. Provides a simple key/value persistent store for lightweight data. Provides the ability to change Web View text size for visual accessibility. Provides a notification pop up for displaying important information to a user. Just like real toast!

Tests

Tests are split by backend (API/plugin), CLI, database SQL, and frontend:

  • tests/ - Backend Vitest tests (API + plugin + CLI)
  • playwright/e2e/ - Frontend Playwright tests
  • supabase/tests/ - SQL tests for functions, RLS, and DB logic
Backend test groups (Vitest):
  • API tests: public/private endpoints and general backend behavior
  • Plugin tests: tests/updates.test.ts, tests/stats.test.ts,
tests/channel_self*.test.ts
  • CLI tests: tests/cli*.test.ts (CLI auth, upload, metadata, etc.)
Run tests: 
# Supabase Edge Functions (default)
bun test:all
bun test:backend
bun test:cli
bun test:front

CLI workspace

bun run cli:build
bun run cli:test
bun run cli:check

Legacy aliases kept for compatibility

bun test:local
bun test:all:local
bun test:cli:local

Database SQL tests (Supabase CLI)

supabase test db

Cloudflare Workers

bun test:cloudflare:all
bun test:cloudflare:backend
bun test:cloudflare:updates

Local Cloudflare Workers (required for cloudflare tests)

./scripts/start-cloudflare-workers.sh

Notes:

  • Tests run in parallel across files. If a test mutates shared data, add
dedicated seed data in supabase/seed.sql.
  • The repository is a Bun workspace monorepo. The Capgo app lives at the root
and the CLI lives in cli/.
  • Capgo's Vitest CLI coverage now resolves the local cli/ workspace by
default, so monorepo changes are exercised together.
  • SQL tests in supabase/tests/ are run by the Supabase CLI test runner.
  • Run bun run supabase:start first so the local DB is available (worktree-isolated).

Dev contribution

Coding Style

  • Use Composition API with
Chat with me