kushbavaria proposes Google Cloud Run deployment for an Ornn-hosted mike instance

kushbavaria/mike describes a PR that wires the mike stack onto Google Cloud Run as two services, adds an Ornn-domain access allowlist, and documents the full GCP provisioning flow. The PR was closed without merging about a minute after opening.

The deployment target is a dedicated GCP project (ornn-mike-20260509) inside the ornn.com organization, with Cloud Run, Cloud Build, Artifact Registry, Secret Manager, and IAM enabled. A dedicated runtime service account was provisioned with Secret Manager read access, and an Artifact Registry repo holds the container images. The stack deploys as two separate Cloud Run services, one for the Express backend and one for the Next.js frontend.

The access-policy layer is specific to Ornn's use case: only @ornn.com email addresses can sign in by default, with an ALLOWED_EMAILS env var as an escape hatch for external advisors. The diff touches auth context, login and signup flows, and a shared access-policy module to enforce this.

Verification was limited: script syntax checks, backend and frontend builds, and an ESLint pass on the access-policy touch points. The author noted that a full frontend lint still trips on pre-existing unrelated errors, and that an actual Cloud Run deploy requires real Supabase, R2, and provider credentials before the deploy script does anything useful. No smoke test against a live environment was performed.

The PR was closed roughly a minute after opening, apparently never intended for upstream. This looks like internal work for Ornn standing up its own hosted instance, submitted to their fork rather than to willchen96/mike.