Clerk satellite apps: shared sessions across domains without breaking auth

TL;DR: Subdomains share sessions with Clerk by default, but separate domains need the primary plus satellite setup. The auth state lives on the primary domain only, and every sign-in flow must run there. Sign-in and sign-up always happen on the primary; satellites transparently redirect users there and back. Create the Clerk application and pick the primary domain during setup.

Multi-domain with satellite applications

The model

One primary domain holds the authentication state. Satellite domains read that state from the primary through a secure handshake. Sign-in and sign-up always happen on the primary; satellites transparently redirect users there and back.

The order

1. Create the Clerk application and pick the primary domain during setup. Build your sign-in flow on the primary domain (for example /sign-in).

2. In the dashboard go to the Domains page, open the Satellites tab, and add each satellite domain following the prompts.

3. Configure each satellite app to know it is a satellite: set the domain and isSatellite flags (env vars or Clerk provider props, depending on your framework).

4. Point signInUrl at the primary domain's sign-in page. In development this is required; in production it is optional but recommended.

5. Deploy and test the full loop: visit the satellite signed out, confirm you are redirected to the primary sign-in, sign in, confirm you land back on the satellite still authenticated.

The traps

• Putting a SignIn component on the satellite. It will not work; auth flows live on the primary by design.

• Assuming this covers subdomains. Authentication across subdomains with shared sessions already works by default and does not need satellites. This guide is for genuinely different domains.

• Passkeys are not recommended across domains because of passkey domain restrictions. If your auth strategy leans on passkeys, keep them on the primary domain flow.

• For non-React frameworks, multi-domain is supported only without server rendering or hydration. Check your framework's standing before committing to the architecture.

Checklist

• Sign out on the primary and confirm the satellite reflects it.

• Each satellite domain is added in the dashboard; undeclared domains get no session handshake.

• Custom domains in production instances are configured before you test the redirect loop, or you will debug DNS as if it were an auth bug.

When to use this

• This covers exactly what the title says: Clerk satellite apps.
• You are setting this up for the first time, or auditing an existing setup.
• You want the key gotchas in one place before you start.

When not to use this

• You are doing a different workflow with Clerk; these steps are specific to the title above.
• You need the full reference docs; this is the short path, not the manual.

Compatibility

• Not pinned to a specific version; follows current Clerk behavior.

Verified live against the Clerk docs 2026-09-26 at https://clerk.com/docs/guides/dashboard/dns-domains/satellite-domains. Auth state lives on the primary domain, satellites are added under the Domains page Satellites tab, sign-in flows must run on the primary, and subdomain session sharing works by default without satellites.