Production Release

The Production Release screen orchestrates a full release of your app. One click here:

1. Bumps the version on both the mobile and API repos
2. Creates GitHub releases (which trigger any CI workflows you have set up)
3. Deploys the API to Google Cloud Run
4. Wires the new Cloud Run URL into your mobile app’s production env

You then go to EAS to kick off the production mobile build that will be submitted to the stores.

What “production” means in Mosayic

There are two environments by default:

• Development — your laptop. Local Supabase, local API server, dev build on your phone.
• Production — Cloud Run + hosted Supabase. Production builds submitted to the App Store and Play Store.

Some teams add a third (staging, beta). Mosayic doesn’t currently template that — you’d add it manually by creating a third Supabase project and a second Cloud Run service.

The pre-flight check

Before letting you cut a release, the dashboard runs a pre-flight on both repos:

Check	Why
Working tree is clean	Uncommitted changes shouldn’t sneak into a tagged release
You’re on the main branch	Releases come from main only
Local main is in sync with origin/main	Avoid releasing local commits that haven’t been pushed

If any check fails, the dashboard tells you what to fix and disables the release button until it’s resolved.

The release flow

1. Pick a version. The dashboard shows your current version and offers buttons for Major / Minor / Patch bumps. You can also enter a custom semver string. The new version is validated to be greater than the current one.

2. Write release notes. A markdown text area. These appear on the GitHub release page and (later) in your App Store / Play Store listings.

3. Click “Cut release”.

   • Mosayic writes the new version into mobile/app.json, mobile/package.json, and api/pyproject.toml.
   • Commits the bump on both repos.
   • Pushes both branches.
   • Creates a v<version> tag and a GitHub release on each repo with your notes.

4. Click “Deploy API”.

   • The dashboard runs gcloud run deploy api-prod --source . --region us-east1 (region defaults to us-east1 but can be changed).
   • This builds a container from your api/ folder and deploys it to Cloud Run.
   • Returns the new service URL when done.

5. Click “Sync API URL to EAS”.

   • The dashboard fetches the Cloud Run URL.
   • Writes it into mobile/eas.json under the production build profile as EXPO_PUBLIC_API_URL.
   • Commits and pushes.

6. Build the mobile binary. From here you go to EAS:

   cd mobile
   eas build --profile production --platform ios
   eas build --profile production --platform android

   Or trigger the builds from the EAS web dashboard. These produce .ipa and .aab files signed for store submission.

7. Submit to the stores. See App Store Submission for the next step.

What if a step fails?

Each step is independent and idempotent.

• Version bump fails because someone else committed: pull, resolve, re-try.
• GitHub release fails because the tag already exists: bump the patch version and try again.
• Cloud Run deploy fails: the dashboard shows the gcloud error. Most often it’s a missing API (gcloud services enable run.googleapis.com) or a permissions issue (the active gcloud account needs roles/run.admin).

Mosayic doesn’t roll back on failure. If the version bump succeeded but the deploy failed, you can still re-run the deploy step.

Tip

The API and mobile repos can be released independently. You don’t have to bump both versions in lockstep — many releases will only need an API change or only a mobile change. The dashboard lets you skip steps that don’t apply.

After a release

Your deployed API now serves real traffic from any production-build mobile clients pointing at it. The local development setup is unaffected — you continue working against your local Supabase and local API. Production is its own thing.