Deployment, fleets & self-hosting

For platform operators and IT: point the desktop app at your own backend, decide who owns updates, and keep a fleet on one known version.

Wingman ships with two deployment shapes, and the first decision is which one you are running. A consumer install is one person downloading the signed Linux package: the app owns its own updates and the defaults are right. An IT deployment is a fleet: your tooling owns the package, updates are staged on your schedule, and the app’s updater is switched off. The same split Claude Desktop uses — and mixing the two on one machine is the main thing to avoid.

Point the app at your backend

Out of the box the desktop app talks to Axelera’s hosted backend: wingman.backend.mode is hosted and the API base URL points at the hosted service. Self-hosting means giving the app your own Supabase project and backend instead — and there is a panel for exactly that.

1. Open the Supabase onboarding panel

   In the desktop app, run Axelera: Supabase Onboarding from the command palette (or open the full-size panel with the onboarding command). The form stores your configuration locally on that machine.

2. Enter your project coordinates

   Fill in the Project Ref (from your Supabase project settings), the Supabase URL (https://<ref>.supabase.co), and the Backend API URL your Wingman backend serves.

3. Paste the keys — they go to secure storage

   Provide the service_role key and, optionally, the anon key. Both are saved to the editor’s secret storage, not to settings.json — they never land in a dotfile that syncs or gets committed.

4. Save, and optionally copy the MCP config

   Save Settings writes the URLs to app settings and the secrets to secure storage. Copy MCP Config puts a ready-made Supabase MCP server entry on your clipboard — it prompts for a personal access token at connect time rather than embedding one.

5. Validate one machine end to end

   Before touching the fleet, prove the pilot: sign in, open Chat, run one Agent Dev task, and send one feedback report. Every one of those exercises a different part of your backend wiring.

Auth mode versus auth strategy

Who owns updates

Updates are where consumer and IT deployments truly diverge. The consumer path is the signed channel: a neutral title-bar dot becomes green only after a healthy/current check and expands to Download update or Fix update only when action is useful. Intentionally managed or disabled updates stay neutral. No package bytes move until the user clicks, Install update asks for administrator authorization through the system prompt, and activation is controlled by a separately reviewed signature — publishing a GitHub release and activating it are separate trust events. Interrupted installs recover; a package left in a doubtful state is flagged for recovery instead of silently retried.

Pin versions for fleets

For fleets, pin versions by installing exact release assets. Every release publishes immutable versioned artifacts: install a specific versioned tag, never a floating “latest”, and use the signed install-wingman.sh bundle for terminal and fleet installs: it verifies the release key fingerprint, signature, and checksums, then restages the package root-owned before apt ever opens it. The exact commands, starting with the packages a minimal system needs, are under Verify signatures before installing (optional) in Install the desktop app. Set update.mode=none on managed machines, and roll the fleet forward by shipping the next exact version through your own tooling when you have validated it.