Skip to main content

Tenants and Sign-up

On a fresh deployment, anyone who can reach your DocAI Fabric address can click Sign up and create an account. Signing up does not just create a user: it creates a whole new tenant (a separate workspace, with its own projects and data) and makes that person its administrator.

That is usually not what you want on your own deployment. This guide shows you how to create tenants yourself and then close public sign-up.

Why sign-up starts switched on​

A brand new deployment has no tenants and no users at all. Invitations can only be sent from inside a tenant, by an administrator who already exists. So if sign-up were switched off from the very first boot, there would be no way for anyone to get in.

Sign-up therefore starts on, so the first tenant can be created, and you switch it off once that tenant exists. From then on, new tenants come from you, and new users come from invitations sent by a tenant administrator.

Creating a tenant sends a welcome email, and that email contains a link back to your deployment. So configure mail before you create anything:

  1. Configure SMTP so the deployment can send email.
  2. Set the application URL so the links in those emails point at the right address.
  3. Send a test email to confirm both are right: 
    da admin config test-email you@yourcompany.com
  4. Create your tenant (below).
  5. Switch off public sign-up (below).

Create a tenant​

This creates the tenant, its first project, and its administrator:

da admin tenant create "Acme Corp" --admin-email admin@acme.com --admin-name "Ada Lovelace"

The new administrator receives an email inviting them to choose a password. The link is valid for 7 days. Once they are in, they can invite the rest of their team from the Team page.

If mail is not working yet​

If you have not set up SMTP, or it is not working, you can still create the tenant and hand over the password yourself:

da admin tenant create "Acme Corp" --admin-email admin@acme.com --with-temp-password

This prints a one-time password. Note two things:

  • It is shown once. It is not stored anywhere and cannot be retrieved later. If you lose it, either the administrator uses "Forgot password?" (which needs working email) or you create the tenant again.
  • Send it over a trusted channel, not by email.

The administrator is forced to choose a new password the first time they sign in, so the temporary one cannot stay in use.

List your tenants​

da admin tenant list

This shows every tenant on the deployment: its id, its name, who administers it, how many members it has, and when it was created. You need the id from this list to delete a tenant.

A tenant marked (orphaned) has no administrator and no members, so nobody can sign in to it. These are empty records left behind by older versions of the CLI. They hold no data and are safe to delete.

Delete a tenant​

This cannot be undone

Deleting a tenant permanently destroys it: its projects, its transactions, and all of its documents. It also removes the users who belonged to no other tenant. There is no undo, no recycle bin, and no soft delete. Make sure you have a backup of anything you might need first.

da admin tenant delete <tenant-id>

The command shows you the tenant it is about to delete (name, administrator, member count) and asks you to type the tenant's name to confirm. Anything else cancels and nothing is deleted.

There is no flag to skip the confirmation, and no command to delete several tenants at once. This is deliberate. If you need to remove more than one, delete them one at a time.

A few things worth knowing:

  • Users in other tenants are kept. If somebody belonged to the deleted tenant and one or more others, they keep their account and their other memberships. Only users whose sole tenant was this one are removed.
  • Deleting your last tenant leaves the deployment empty. If public sign-up is also switched off, nobody can get back in, and you will need to create a tenant again with da admin tenant create before anyone can sign in.

Switch off public sign-up​

Once a tenant exists, close the door:

da admin config set auth.self_signup_enabled false

This takes effect immediately, with no restart. The Sign up link disappears from the login page, and the deployment refuses any attempt to sign up even if somebody goes to the sign-up address directly.

Nothing else is affected. Existing users still sign in, invitations still work, and "Forgot password?" still works.

To check the current setting, or to switch it back on:

da admin config get auth.self_signup_enabled
da admin config set auth.self_signup_enabled true

Adding more users​

After sign-up is off, users are added inside a tenant, by that tenant's administrator, from the Team page. You only need the CLI again when you want to create another separate tenant.

Notes​

  • Google sign-in is available on the DocAI Fabric cloud service only. It is not offered on self-hosted deployments, whatever your sign-up setting is.
  • If a change does not seem to have taken effect on a deployment running several copies of the application, allow up to 30 seconds for every copy to pick it up.