Google log-in says "continue to xxxx.supabase.co" instead of my app name. Why?

• Users click "Sign in with Google" and Google says "Choose an account to continue to abcdefghijklmnop.supabase.co".
• Sign-in works, but users (or your client) say it looks like phishing, and some drop off at that screen.
• On a Lovable app using "Your own credentials", the consent screen shows your Google Cloud project's details rather than what you expected.

Supabase's Google guide says that if you don't set up a custom domain, "users will see <project-id>.supabase.co which does not inspire trust and can make your application more susceptible to successful phishing attempts" (Supabase: Login with Google).

Google decides what to show based on your OAuth app's branding. Google's help says that if you use only non-sensitive scopes (like email and profile), full app verification isn't required, "However, if you want your app to display an app name and logo on the OAuth consent screen, you will need to complete a lighter-weight verification process known as 'brand-verification'" (Google Cloud Help: OAuth app verification).

Option A: verify your brand with Google (shows your name and logo)

1. In the Google Cloud Console, open the Google Auth Platform's Branding section for the OAuth client you use with Supabase. Supabase's docs name this section (Supabase: Login with Google).
2. Fill in App name, User support email and App logo, the App domain links (home page, privacy policy, terms of service), your Authorized domains and the Developer contact information (Google Cloud Help: Manage OAuth App Branding). Add the authorized domains first; Google says to add them before the home page, privacy policy and terms URLs.
3. Click Verify Branding. Google says the check usually completes in a few minutes, but some apps go to an additional review, and Supabase notes that "Brand verification is not automatic and may take a few business days." Once it passes, click Publish branding within 7 days.
4. Google requires the home page to be "hosted on a verified domain you own" and points to Google Search Console to check that your domains are verified (Google Cloud Help: Manage OAuth App Branding). Verify the domain in Search Console first if you haven't.

This changes the name and logo shown. It doesn't, by itself, remove the supabase.co callback domain.

Option B: add a custom domain to your Supabase project (paid, replaces supabase.co)

Supabase says custom domains "are available as a paid add-on for projects on a paid plan" (Supabase: Custom domains).

1. Pick a subdomain of your app, such as auth.yourapp.com or api.yourapp.com. Supabase recommends this pattern.
2. Create a CNAME record pointing it to <project-id>.supabase.co., then add it with the Supabase CLI (supabase domains create --project-ref <ref> --custom-hostname auth.yourapp.com) and add the TXT verification record it returns.
3. Before activating, add the new callback to your Google OAuth client's Authorized redirect URIs, alongside the old one: - https://<project-id>.supabase.co/auth/v1/callback - https://auth.yourapp.com/auth/v1/callback Supabase warns that "Supabase Auth will use the custom domain immediately once activated" and "OAuth flows will advertise the custom domain as a callback URL", so skipping this step breaks Google sign-in.
4. Activate with supabase domains activate --project-ref <ref>.
5. Optionally switch your client to the new URL: createClient('https://auth.yourapp.com', '<publishable key>'). The old project domain keeps working, so this isn't urgent.

Supabase also offers vanity subdomains (your-brand.supabase.co) on paid plans, configured via the CLI only. That still shows supabase.co, just with your name.

On Lovable Cloud

Lovable's docs describe two setups for Google sign-in on its built-in backend (Lovable: Google authentication):

• Managed by Lovable (default): Lovable says the consent screen "Shows your application name."
• Your own credentials: "the Google consent screen is fully controlled by your Google Cloud project", so you do Option A in your own Google Cloud project. Lovable's docs give the path as More → Users → Settings → Google.

Paste this into Lovable, Bolt, Cursor, Replit, v0 or whichever tool you build with:

I'm adding a Supabase custom domain, auth.<yourapp.com>, so Google sign-in stops showing <project-id>.supabase.co. Help me with the code side only:
1. Find where the Supabase client is created and make the Supabase URL come from an env var (VITE_SUPABASE_URL or NEXT_PUBLIC_SUPABASE_URL) instead of a hard-coded supabase.co URL.
2. Find any hard-coded "<project-id>.supabase.co" URLs (auth callbacks, storage links, Edge Function calls) and list them.
3. Don't change the auth flow, the redirectTo values or the UI.
Then give me a checklist: add https://auth.<yourapp.com>/auth/v1/callback to Google's Authorized redirect URIs BEFORE activating the domain, then switch the env var and rebuild.

1. In a private window on your live site, click "Sign in with Google".
2. Check what the account picker says: your custom domain (Option B) and/or your app name and logo (Option A, after verification is approved).
3. Finish signing in and check you land back in your app, signed in.

Heedza doesn't click "Sign in with Google" or sign in at all. It checks on a schedule that your login and signup pages load and show their forms, and sends a screenshot and a fix prompt when one doesn't. If a domain change like this one breaks your login page, that's the kind of thing it reports. Want a quick look at your security basics? The free scan reports exposed keys and missing security headers on your homepage.