Auth0 multiple custom domains is too expensive, what are the alternatives?

You run several brands on one Auth0 tenant, and each brand wants its login page on its own domain, like login.brand-a.com and login.brand-b.com. Auth0 offers that as Multiple Custom Domains, and only on its Enterprise plan. Before you pay for it or switch providers, check which problem you have. Branded login pages need custom domains. Many app domains that share one user pool don’t.

What is an Auth0 custom domain?#

An Auth0 custom domain is the domain that Auth0 serves your login page and its sign-in endpoints on, like login.example.com instead of example.auth0.com. Auth0 gives two reasons to use one: people trust a login page under your own brand, and a vanity URL is harder to phish. You also need a custom domain to customize Universal Login page templates.

A custom domain is not where your app runs. Your app domains, like brand-a.com and shop.brand-b.com, are the Allowed Callback URLs in each application’s settings. They don’t need custom domains at all.

Auth0’s pricing page lists a custom domain on every plan. On the Free plan you need a credit card on file for verification, and Auth0 says it isn’t charged.

Why do teams need more than one?#

• Several brands, one user pool. A company with brands on separate domains wants each login page to show that brand’s address, while people keep one account.
• White-label B2B products. Customers want their own users to sign in on the customer’s domain, not on yours.
• Regional sites that are marketed as separate companies.

Several login domains also split things that one domain keeps together. Auth0 documents that each custom domain keeps its own passkey enrollment, so a passkey created on login.brand-a.com doesn’t work on login.brand-b.com.

Which Auth0 plans include multiple custom domains?#

Multiple Custom Domains (MCD) lets one Auth0 tenant serve its login page on several custom domains. Auth0’s documentation lists it for Enterprise customers, on both Public Cloud and Private Cloud, and Auth0 announced general availability in April 2026.

What Enterprise costs depends on your contract, so start from Auth0’s pricing page and the MCD documentation.

The usual workaround below Enterprise is one tenant per brand, each with its own custom domain. Each tenant is then a separate user pool with its own settings. Someone who uses two of your brands has two accounts, and you configure everything twice.

What are the alternatives?#

One shared login domain for all brands#

Keep a single custom domain, like login.example-group.com, for every brand. Each brand keeps its own app domain as a callback URL. Universal Login page templates can still change the page for each application, with variables such as application.name and application.logo_url.

You keep one user pool, and because every sign-in happens on the same domain, one passkey works for every brand. You give up a login address per brand: everyone sees the shared domain.

Separate app domains from login domains#

Many teams who look at MCD only need many app domains, and in Auth0 those are callback URLs, not custom domains. Auth0 accepts a wildcard for subdomains in callback URLs but advises against it in production, and suggests an {organization_name} placeholder for setups with one subdomain per tenant. See wildcard redirect URIs for the trade-offs.

When you compare hosted providers, ask two questions separately. How many app domains can you register, and can your server add them through an API? And is a branded login domain included, an add-on, or not offered at all?

Self-hosted: every domain is yours#

Open-source identity servers that you run yourself have no per-domain fee, because they run on domains you control:

• Keycloak uses hostnames you configure, and a realm can have its own frontend URL.
• Zitadel picks a virtual instance by the domain a request arrives on, and its System API can add more domains, though its docs recommend a single domain for most setups.
• Authentik has brands: each one applies to a domain or a domain wildcard, with its own title, logo and default flows.

The cost moves to operations: servers, the database, upgrades, backups and security patches are yours. Keycloak alternatives compares simpler options.

Where loginos fits#

loginos is a hosted OpenID Connect provider for products that run on many domains. Be clear about what it is and what it isn’t before you compare it with MCD.

What loginos does. A platform, your product in loginos, has no limit on app domains, the addresses where people start and come back to. Add them in the console, register up to 1,000 at once from your server, cover subdomains with a verified wildcard, or let your server confirm new domains the first time they’re used. All of a platform’s domains share one user pool: someone who joined on one brand’s site is already a member on the others, and comes back without a form. Passkeys belong to loginos.io, so one passkey works on every domain.

What loginos doesn’t do. The sign-in page is always on loginos.io, showing your platform’s name and logo. loginos offers no white-label or custom login domain. If your brands need login.brand-a.com, loginos is the wrong tool: look at MCD, separate tenants or a self-hosted server.

curl -X POST https://loginos.io/api/v1/domains \
  -u "$LOGINOS_APP_KEY:$LOGINOS_APP_SECRET" \
  -H "content-type: application/json" \
  -d '{"hosts": ["brand-a.com", "shop.brand-b.com", "brand-c.net"]}'

The call is idempotent, so you can run it every time you launch a brand. The callback path is the same on every domain, and you set it once in the console’s Domains tab (Callback path). A platform shows one name and logo on the sign-in page. If each brand must show its own, create one platform per brand: people still use the same loginos account on all of them, but each platform has its own members and roles.

loginos has no paid plans today, so you can start without a card. The quickstart covers the two routes each domain needs.

Frequently asked questions#

Do my app domains need Auth0 custom domains?#

No. App domains are the Allowed Callback URLs in each application’s settings. A custom domain only changes where Auth0 serves the login page and its endpoints.

Will one passkey work across my brands’ login domains?#

Not with separate login domains. Auth0 documents that each custom domain keeps its own passkey enrollment, because a passkey is tied to the domain it was created on. A shared login domain, or a provider where sign-in always happens on one domain, gives people one passkey for every brand.

Is self-hosting Keycloak cheaper than Auth0 Enterprise?#

It has no license or per-domain fee, but running it isn’t free: servers, a database, upgrades, backups and on-call time all cost money. Compare that full cost with your Auth0 quote, not just the license line.

Does loginos offer custom login domains?#

No. Sign-in always happens on loginos.io, with your platform’s name and logo. Your domains are where people start and come back to, and a platform can have as many as you need.