Auth on SupaHost

How Supabase Auth works on SupaHost: what each project gets, which sign-in methods are available, where the settings live in the dashboard, and what isn't configurable.

Every SupaHost project runs its own copy of Supabase Auth (the open-source GoTrue server, currently v2.197.0). It stores users in your project's database, issues JWTs that Row Level Security understands, and sends sign-up, magic link and password reset emails for you. Because it's the same server Supabase uses, supabase-js and the other client libraries work without changes.

Auth for a project lives at:

https://app-one.acme.supahost.space/auth/v1

You rarely call that URL yourself. The client library does it when you pass your project URL and anon key to createClient.

What you can use

Feature On SupaHost
Email and password Yes. See Email and password sign-in
Magic links and email OTP codes Yes. See Magic links and email OTP
OAuth (social login) Yes, 19 providers. See Social login
SAML 2.0 single sign-on Yes, for business customers' identity providers (Okta, Entra ID and others). See SAML 2.0 single sign-on
Anonymous sign-ins Yes, off by default. See Anonymous sign-ins
Multi-factor authentication TOTP (authenticator apps) through the supabase.auth.mfa API. See MFA
Identity linking Automatic, plus manual linking when enabled. See Linking identities
Admin API Yes, with the service_role key on a server. See Managing users
Server-side auth (cookies, SSR) Yes, with @supabase/ssr. See Server-side auth
Phone and SMS sign-in Not available
Phone MFA Not available
Custom SMTP Not available. Emails are sent by SupaHost
Auth hooks (custom access token, send email and so on) Not configurable. There's no setting for them
CAPTCHA Not configurable. See Rate limits and abuse protection

Where the settings are

Open Dashboard → your project → Auth tab. It has four cards:

  • Auth: "App name" (the sender name and header of your Auth emails, up to 60 characters), "Site URL" and "Redirect URLs". Saved with Save Auth settings. See Site URL and redirect URLs.
  • Auth emails: the five email templates (Confirm sign-up, Magic link, Reset password, Invite, Change email). See Auth emails and templates.
  • Sign-in & security: toggles for "Email sign-in", "Disable new sign-ups", "Skip email confirmation", "Anonymous sign-ins" and "Manual identity linking", plus "Minimum password length" (6 to 72) and "Access token lifetime" (300 to 604800 seconds). Saved with Save sign-in settings.
  • OAuth providers: one row per provider with its Client ID, Client secret and, for a few providers, a URL field. The callback URL to give each provider is shown at the top of the card.

Only the instance owner can change these settings. Invited team members see the cards read-only. Saved changes reach the project within about a minute, because the platform applies them on its next pass over your instance.

A first sign-up

With email sign-in on (the default), this is enough to create a user and send a confirmation email:

import { createClient } from '@supabase/supabase-js'

const supabase = createClient(
  process.env.SUPABASE_URL!,      // https://app-one.acme.supahost.space
  process.env.SUPABASE_ANON_KEY!
)

const { data, error } = await supabase.auth.signUp({
  email: '[email protected]',
  password: 'a-long-passphrase',
  options: { emailRedirectTo: 'https://recipes.example.com/welcome' },
})

The user gets an email from [email protected], shown with your App name as the sender. After they confirm, they can sign in and every request they make carries a JWT with their user id, which your policies read with auth.uid():

create policy "Cooks read their own recipes"
on public.recipes for select
to authenticated
using ((select auth.uid()) = user_id);

Things to know before you build

  • Set the Site URL early. If it's empty, Auth falls back to http://localhost:3000, so confirmation links in production emails would point at localhost.
  • Emails are rate limited. Auth sends at most 30 emails in its rate-limit window (GOTRUE_RATE_LIMIT_EMAIL_SENT=30) and the number can't be raised. Plan bulk invites accordingly.
  • Keys are the legacy JWT kind. Projects have an anon key and a service_role key, both HS256 JWTs. There are no sb_publishable_ or sb_secret_ keys, and the keys and JWT secret can't be rotated. See API keys.
  • Custom domains change the callback host. Once a custom domain is active, Auth uses it for links and OAuth callbacks, so OAuth apps need the new callback URL. See Custom domains.
  • Branches start with default Auth settings. A branch copies users if you copy data, but not Auth settings or OAuth providers. Set them on the branch if you need them there. See Branching.
  • Imports bring users, not settings. Importing from Supabase Cloud copies users with their passwords and identities, but not the site URL, redirect URLs or provider keys. Users sign in again once, because the JWT secret is different.

Where to go next

Updated 11 November 2026 · View as Markdown · Something wrong or missing? Tell us