Operating Mushi Mushi

This section is for maintainers running Mushi Mushi Cloud or shipping the open-source SDK packages, not for app developers integrating the SDK. If you are integrating Mushi Mushi into your app, start at Quickstart instead.

Mushi Mushi is OSS-first: the hosted product runs the same code as this repo, plus its own tuning data (prompts and scoring weights kept as configuration). Self-hosters can reuse every deploy path described here. See Self-hosting.

What lives here

Page	Audience	Covers
Deployment & releases	Maintainers	npm SDK publish (Changesets + OIDC), edge functions, admin SPA, docs, DB migrations
CI runners	Anyone running GitHub Actions	Where your tests run and why a fix waits, a broken fix vs a stopped test machine, and `mushi runner add`
Local workers	Anyone fixing reports on their own machine	`mushi work --daemon` as a service, its guards and key, and the console’s Pipeline → Workers tab

The independent deploy paths

Mushi Mushi has six delivery pipelines that ship independently, so a change to one never blocks the others:

npm SDK packages: release.yml (Changesets version PR → merge → OIDC publish).
Supabase Edge Functions: deploy-edge-functions.yml (path-filtered push to master, plus a nightly full deploy).
Admin console SPA: deploy-admin.yml (S3 + CloudFront).
Docs site: deploy-docs.yml (S3 + CloudFront).
Mushi Mushi Bounties marketplace: deploy-testers.yml (S3 + CloudFront at /testers).
Hosted MCP proxy: deploy-hosted-mcp.yml (CloudFront route and OAuth discovery documents for /hosted-mcp).

Database migrations are manual (supabase db push) and are never run by CI.

See Deployment & releases for the full runbook.