Skip to main content
Paid Feature

This is a paid feature.

For self hosted users, Sign up to get a license key and follow the instructions sent to you by email. Creation of tenants is free on the dev license key.

This feature is already enabled for managed service users. Creation of additional tenant is free on the provided development environment.

Run multiple apps / dev envs using the same SuperTokens core

Just like how you can create multiple tenants / user pools within one SuperTokens core, you can create multiple apps within one core as well:

  • Each app is isolated and can have several tenants.
  • Each app can be assigned its own database, or share a database with another app (and yet be logically isolated).
  • Each app can have its own set of core and db configs. If a specific config is not explicitly set for an app, it will inherit it from the base config.yaml / docker env vars config.
  • The core and db configs of each tenant within an app are inherited from the configs of that app.

You can use this feature to use one SuperTokens core deployment across several indepedent apps within your company, and / or to create multiple dev environments (dev, staging, prod etc..) for one app without having to deploy individual SuperTokens core instances.

Create a new app in the core#

In order to create a new app in the SuperTokens core, you can use the following cURL command:

curl --location --request PUT '/recipe/multitenancy/app' \
--header 'api-key: ' \
--header 'Content-Type: application/json' \
--data-raw '{
"appId": "app1",
"thirdPartyEnabled": true,
"passwordlessEnabled": true,
"emailPasswordEnabled": true,
"coreConfig": {...}
  • The above command will create (or update) an app with the appId of app1.
  • It will also create a default tenant for this app with the tenant ID of public (i.e. the default tenantId)
  • You can set various core configs for this app (see the config.yaml / docker env var options for your core). The core configs for a new app will inherit from the the configs provided in the config.yaml / docker env (or our edit config dashboard for managed service).
  • By default, all the login methods are enabled for a new app (specifically, the public tenant of the new app), but you can pass in false to any of the login methods specified above to disable them.

Even if a login method is enabled for a tenant, you will still require to initialise the right recipe on the backend for sign up / in to be possible with that login method. For example, if for a tenant, you have enabled the passwordless login method, but don't use the passwordless (or a combination recipe that has passwordless) on the backend, then end users will not be able to sign up / in using the passwordless APIs cause those APIs won't be exposed via our backend SDK's middleware.

Cofiguring the app ID during backend SDK init#

Whilst one core can have multiple apps, you must use a dedicated backend (integrated with our backend SDK) per app. For example, if you have two apps, and both use a NodeJS backend, then you need to configure one app's backend to have appId as app1 (as an example), and the other app's backend to have appId as app2. You can specify an appId on the backend SDK supertokens.init by appending the appId to the connectionUri as shown below:

import supertokens from "supertokens-node";

supertokens: {
connectionURI: "http://localhost:3567/appid-app1",
appInfo: {
apiDomain: "...",
appName: "...",
websiteDomain: "..."
recipeList: []
  • In the above code snippet, we tell the backend SDK that the appId to use for this app is app1. You can pick your own app ID, but whatever it is, you need to add it as shown above.
  • It is important to prefix the app ID with appid- as that enables ths SuperTokens core to reliably detect the app that the query is for.
Looking for older versions of the documentation?
Which UI do you use?
Custom UI
Pre built UI