Auth runtime settings out of sync with Dashboard — Google OAuth disabled and custom SMTP ignored

[brianbeautyplatform]

Hi,

I’m trying to determine whether this is a known Supabase Auth / GoTrue issue or whether I’m missing a configuration step.

Expected behaviour

My project configuration shows:

Google OAuth enabled
Custom SMTP configured

I would therefore expect:

/auth/v1/settings to expose Google as enabled
Google OAuth authorization to work
Auth emails to be sent through the configured SMTP provider
Actual behaviour

The live Auth service appears to be using different configuration:

GET /auth/v1/settings returns external.google = false
Google OAuth returns Unsupported provider
emails still appear to be sent/fallback through noreply@mail.app.supabase.io
the project also hits the default Auth email rate limit, which suggests the configured custom SMTP is not being used
What I’ve checked
application is using the correct Supabase project URL
correct project keys/environment are being used
Google provider is enabled in the Dashboard
custom SMTP configuration is saved
SMTP connection settings/port have been rechecked
What seems unusual

The Dashboard / project configuration and the actual Auth runtime behaviour do not appear to match.

This makes me wonder whether the GoTrue/Auth service has stale configuration or has failed to reload the latest project settings.

Question

Has anyone encountered this before?

Is there any supported way to force the Auth service to reload/restart its configuration, or does this require intervention from Supabase Support?

I can provide sanitized config output or logs if needed.

[Sweta0519]

When the Dashboard and GET /auth/v1/settings disagree, it is almost never a stale GoTrue process. In the cases I have seen it was a second writer changing the same config, and the Dashboard only shows the last value it saved. Two checks settle it in a few minutes.

1. Read the config the Auth service is actually running with

The Management API returns the live Auth config, independent of what the Dashboard renders:

curl -s https://api.supabase.com/v1/projects/<project-ref>/config/auth \
  -H "Authorization: Bearer <personal access token>" \
  | jq '{external_google_enabled, smtp_host, smtp_admin_email, rate_limit_email_sent}'

(Personal access token from Account → Access Tokens. Docs: https://supabase.com/docs/reference/api/v1-get-auth-service-config)

• If this shows external_google_enabled: false and smtp_host: null, the Dashboard values were overwritten after you saved them, and the Auth service is faithfully running the overwritten config. Go to step 2.
• If it shows true and your SMTP host but /auth/v1/settings still says false, then it really is a runtime issue. Restart the project (Project Settings → General → Restart project if your role shows it, otherwise POST https://api.supabase.com/v1/projects/<ref>/restart with the same token; it restarts the database too, so expect a few seconds of downtime) and check again. If it still disagrees after a restart, that is a Supabase Support case; include the two outputs.

2. Find the second writer

The two usual ones:

• supabase config push, or a CI job that runs it. It writes every property that supabase/config.toml declares to the hosted project; properties the file does not declare are left alone. So a file that declares [auth.external.google] enabled = false (the supabase init template ships providers that way), or an [auth] section written for local development and never updated for production, turns Google off again on every deploy. The same applies to a declared [auth.email.smtp] block with local or placeholder values, which replaces your Dashboard SMTP; the fallback sender noreply@mail.app.supabase.io plus the default email rate limit is exactly what that looks like. Fix: declare the production values (secrets via env(...)), run supabase config diff to preview (available in recent CLI versions), then push once from your machine and re-check with the config/auth call above.
• Branching. If the app talks to a preview branch's URL, that branch has its own Auth config synced from config.toml, and the Dashboard you are looking at may be production. Compare the project ref in NEXT_PUBLIC_SUPABASE_URL (or equivalent) with the ref in the Dashboard URL.

If neither applies, share the sanitized output of the config/auth call and whether the project uses the CLI or branching, and I am happy to look again.

Edited: corrected the config push paragraph. An undeclared section is not written by the current CLI; only declared properties overwrite the hosted values.

[Rocin1738]

[Y]

[Rocin1738]

Microsoft and Bing brought it to my attention

[Rocin1738]

I have September 3rd between all started

[tuyakhov]

@Sweta0519's config/auth check is the right first step. Google OAuth and custom SMTP both reverting at the same moment is what you'd expect if something rewrites the Auth config as a whole, like a deploy. A process that failed to reload is less likely.

If it does turn out to be supabase config push, also check the rate limit in your config.toml. The CLI template ships with:

[auth.rate_limit]
email_sent = 2

So even after you fix the SMTP block, pushing that file can keep you at 2 emails an hour. That would explain the rate limit you're hitting. With custom SMTP the limit normally starts at 30 an hour and can be raised under Authentication → Rate Limits. Set email_sent to the value you actually want in the file, or the next push will override the dashboard again.

What does config/auth return for external_google_enabled, smtp_host and rate_limit_email_sent?

[Rocin1738]

Do research,than run or pull a respitory