Separate teams with tenants
Assign namespaces, storage boundaries, roles, branding, and limits without mixing teams' files.
On this page
Create a tenant
A platform administrator creates tenants from Tenants. Choose a key, label, administrator group, and limits for total bytes, links, and concurrent sessions. Users whose groups match the tenant's administrator group can select that tenant from the workspace switcher.
Named tenants publish into .vot-tenants.stage/<tenant>/ beneath both content roots. The default tenant uses its own root and cannot write into those reserved directories.
Set limits
Tenant quotas bound the namespace as a whole; request-link limits can be more restrictive. Update limits and group assignments on the existing tenant rather than recreating it. In the administrator API, null clears a quota to unlimited and zero is rejected.
Check free storage in addition to quota usage. Quotas do not reserve physical disk capacity, and temporary transfer or delivery work needs space too.
Branding and domains
A tenant can have a name, accent color, and logo on its sender and recipient pages. A separate hostname requires reverse-proxy and DNS configuration. Pointing another domain at the same instance does not create an additional authorization boundary: request and delivery links work on every hostname reaching that instance.
Offboarding
Revoke principals and remove their identity-provider groups before deleting a tenant. Tenant deletion removes its namespace row and purges its reserved receive and outbound directories. Explicit deletion is separate from automatic retention and legal hold.
If a purge fails after the row was removed, retry the deletion to remove the remaining reserved directory. A similarly named default-tenant path is separate and is not part of that purge.
Backups and replicas may retain older tenant rows or file bytes until their own retention policies expire. Coordinate backup erasure separately when required.