Multi-tenancy with domain based routing

[service-paradis]

I'm looking to migrate to next-intl, but I'm not sure if my client current use case is compatible. Here is a quick summary:

We have 2 domains, say foofrench.ca and fooenglish.ca. We dont use any pathname prefixes, locale is defined based on domains only. At first after looking at the documentation, I was thinking about something like the following:

export const routing = defineRouting({
  defaultLocale: "fr",
  domains: [
    {
      defaultLocale: "fr",
      domain: "foofrench.ca",
      locales: ["fr"],
    },
    {
      defaultLocale: "en",
      domain: "fooenglish.ca",
      locales: ["en"],
    },
  ],
  localeCookie: false,
  localeDetection: false,
  localePrefix: "never",
  locales: ["fr", "en"],
});

Now, the tricky part where I'm not sure how it can be configured and if it is even supported. We have multi-tenants that can be accessed in both language (ex. tenant1.foofrench.ca and tenant1.fooenglish.ca both works and is displayed in specific locale). We also have a main website that also works for both language (ex. www.foofrench.ca and www.fooenglish.ca)

There are many tenants and this is quite dynamic, so I cannot add them all hardcoded in the configuration.

Is there a way to specify a wildcard or something for the domain part maybe (ex. domain: "*.foofrench.ca",)?

[amannn]

Hey, that's an interesting use case!

I think to implement this, a routing structure like app/[locale]/[tenant] could be really helpful to enable caching locales (based on the top-level domain) and tenants (based on the subdomain). Not sure if your www variants can be treated as a tenant, otherwise I'd move them to app/[locale]/(www).

While you can theoretically configure additional rewrites with the next-intl middleware, I think this is a reasonable use case where you just don't use the middleware from next-intl at all and implement your custom one. Also the navigation APIs are likely not necessary.

If you do that, in order to be able to provide a locale to APIs from next-intl, it's important that you use setRequestLocale based on your locale param. After that, this should work fine.

Closely related to this, next/root-params will be the even cleaner solution to this and allows you to read your top-level segments in i18n/request.ts to return a corresponding locale (without setRequestLocale). It's theoretically already available in the latest Next.js releases (15.5., 16+), but not documented yet.

But yes, this is surely a supported use case—hope this helps!