FusionAuth
    • Home
    • Categories
    • Recent
    • Popular
    • Pricing
    • Contact us
    • Docs
    • Login

    What are the pros and cons of using the default tenant?

    Scheduled Pinned Locked Moved Unsolved
    Q&A
    2
    3
    631
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • G
      gg-dev
      last edited by

      The default tenant includes the FusionAuth application – is it better to create a separate tenant for your application(s), or to use the default tenant?

      What are the pros and cons?

      danD 1 Reply Last reply Reply Quote 0
      • danD
        dan @gg-dev
        last edited by

        @gg-dev This is a great question. It depends on what you want to do and how complex your integration is.

        For load and migration testing, we recommend using a separate tenant as that makes it easy to remove many users repeatedly (you just drop the tenant).

        The only Application which must live in the default tenant is the FusionAuth application (the admin UI which can be used to configure and manage FusionAuth itself).

        If you are planning to do all management via API or other config management tools, you might not care much about the FusionAuth application and so might be fine with everyone in the same tenant. More about config management: https://fusionauth.io/docs/v1/tech/admin-guide/configuration-management

        If you think you want different tenant settings (password complexity, themes, password hashing, MFA options) for the majority of your users and your FusionAuth admin users, then using two or more tenants can make sense.

        If you are private labelling your app and have multiple user spaces, then you'll want multiple tenants. More here: https://fusionauth.io/blog/2020/06/30/private-labeling-with-multi-tenant

        Using a separate tenant allows for more separation:

        • no way to accidentally register a normal user for the FusionAuth admin application
        • can lock API keys down to a separate tenant so that they could never be used to modify FusionAuth or add users
        • users can have different sets of credentials for the user tenant and the default tenant

        Downsides of using multiple tenants:

        • can't share one password or SSO between other applications and the admin UI (for admin users)
        • have to apply the tenant id header for most API calls

        --
        FusionAuth - Auth for devs, built by devs.
        https://fusionauth.io

        G 1 Reply Last reply Reply Quote 0
        • G
          gg-dev @dan
          last edited by

          Thanks Dan. I think we'll go with separate tenants.

          (Apologies for the late reply, I wasn't auto-subscribed to this topic.)

          1 Reply Last reply Reply Quote 1
          • First post
            Last post