Bring-your-own storage

Scenario: Your company policy requires all user screenshots to stay inside your own AWS account, not a third-party storage bucket.

By default screenshots and crash dumps go to a private Mushi-managed Supabase Storage bucket. BYO storage pins them to your own bucket instead: credentials live in Supabase Vault, URLs are signed server-side, and the admin console shows screenshots the same way from either backend.

Supported backends

Setup

In the admin console: BYO storage (/storage).

1. Select your provider.
2. Fill in the fields for it:
   • S3 / R2: bucket (exact name) + region + access key ID + secret access key
   • GCS: bucket + service-account JSON
   • MinIO: endpoint (a public https URL, e.g. https://minio.example.com) + bucket + region + credentials
3. Click Save. Raw credentials are written to Supabase Vault; the settings row keeps only the Vault references, and the keys are never echoed back.

The bucket must already exist. Mushi Mushi never creates buckets.

What moves (and what doesn’t)

• New reports ingested after the switch land in your bucket.
• Existing reports stay in the Mushi-managed bucket; they are not migrated automatically.
• Edge Functions sign the URLs server-side. For your bucket the lifetime is signed_url_ttl_secs (default 3600 seconds, 60 to 604,800 allowed).

Health check

The BYO storage page has a health check (POST /v1/admin/storage/:projectId/health) that uploads a small _mushi_health_<timestamp>.txt object and deletes it again. The result is stored as healthy or failing with the last error, and the page shows it. If an upload to your bucket fails, the report is still saved, without its screenshot, and the error is logged; run the health check after any credential change.

Permissions required