Skip to content

What is multi-tenancy in Notory?

Requires Pro

A tenant (German: Mandant) is a self-contained organization within your Notory installation: with its own users, assets, custom fields, branding, its own SSO configuration, and its own plan (license tier). Multi-tenancy means running several such tenants in parallel — fully isolated from one another. The multi_tenant feature is included from the Pro plan; how many tenants your installation may have at most is defined in the product license (max_tenants).

  • Plan: multi_tenant is unlocked from Pro onward. Without a license (Community mode), the installation is limited to 1 tenant.
  • Tenant limit: set by the product license (max_tenants; e.g. Elite: 50, Enterprise: unlimited). Once reached, creation is rejected with 403.
  • IT service providers / MSPs: one tenant per customer — customers never see each other.
  • Corporate structures: one tenant per subsidiary or business unit, each with its own branding, language, and plan.
  • Separate environments: e.g. production vs. lab, with different policies (such as mandatory 2FA for only one tenant).

Each tenant comes with its own independently configurable properties:

PropertyConfigurable per tenant
Name & slugyes (slug: a-z, 0-9, - only)
Plan (license_tier)yes — Community, Basic, Professional, Elite, Enterprise
Branding (logo, primary/secondary color)yes
Mandatory 2FA (require_2fa)yes (only with a multi-tenant license)
Default language, inline helpyes
Recycle bin (enabled, retention days)yes (overrides the instance default)
Quotas (records, storage)yes
SSO provider (OIDC)yes — configured per tenant
Visible modulesyes — show/hide categories
  • Plan per tenant, capped by the installation. Each tenant has its own plan (license_tier). What’s effective is always the intersection of the tenant’s plan and the installation’s product license — a tenant can never have more than what the installation as a whole is licensed for. The asset limit is also derived from this intersection (e.g. a Basic tenant: 250 assets).
  • A user belongs to exactly one tenant. Email and username are unique system-wide; the account is permanently tied to its tenant. Only super admins work across tenants.
  • Isolation at the database level. Every request runs in the context of exactly one tenant — enforced via row-level security, not just an application filter. Details: Tenant isolation.
  • “Infrastructure” is tied to multi-tenancy. The Infrastructure & Tenants module (site groups, tenant groups) depends on the same multi_tenant feature and is therefore also available from Pro.