# 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.