Multi-Tenancy Overview

Multi-Tenancy Overview

Mantis provides full multi-tenant support, enabling organizations to isolate resources, users, and deployments by tenant.

Overview

Multi-tenancy allows a single Mantis installation to serve multiple customers, teams, or organizational units while maintaining strict data isolation.

Key Features

Feature	Description
Resource Isolation	Tenants cannot see or access other tenants’ resources
Solution Entitlements	Assign solutions per tenant/environment
Target Assignment	Bind targets to specific tenants
Variable Scoping	Tenant-specific configuration variables
User Scoping	Users belong to specific tenants
Audit Isolation	Audit logs filtered by tenant

Tenant Model

Tenant Fields

Field	Type	Description
id	UUID	Unique identifier
name	String	Unique tenant name
description	String	Optional description
logo_url	URL	Optional branding logo
contact_email	Email	Primary contact email
created_at	DateTime	Creation timestamp
updated_at	DateTime	Last update timestamp

Architecture

Resource Hierarchy

Resource Scoping

Actions, Sequences, Solutions, and Environments each carry a nullable tenant_id column, so they are optionally tenant-scoped:

• When tenant_id is NULL, the resource is global — visible to every tenant (and to global/admin users).
• When tenant_id is set, the resource is tenant-private — visible only within that tenant.

Level	Resources	Visibility
Global	Actions, Sequences, Solutions, Environments (when tenant_id is NULL)	All tenants
Tenant (optional)	Actions, Sequences, Solutions, Environments (when tenant_id is set)	Owning tenant only
Tenant	Targets, Variables, Users, Deployments	Tenant-only
Junction	Solution-Environment links, Target assignments	Per-tenant configuration

User Scoping

Admin Users (Platform Level)

Users with tenant_id = NULL:

• See all tenants
• Manage platform resources
• Configure any tenant
• View all deployments

Tenant Users

Users with tenant_id set:

• See only their tenant
• Access entitled solutions/environments
• Deploy to assigned targets
• View tenant-specific audit logs

Solution Entitlements

Tenants don’t have direct access to solutions. Instead, you grant access through tenant-solution-environment links:

Tenant	Solution	Environment	Active
Acme Corp	WebApp	Production	✓
Acme Corp	WebApp	Staging	✓
Acme Corp	API	Production	✓

Target Assignment

Targets can be assigned to tenants globally or per-environment:

Target	Tenant	Environment	Scope
web-01	Acme Corp	Production	Single environment
web-02	Acme Corp	(all)	All environments
api-01	Acme Corp	(all)	All environments

Variable Scoping

Tenant variables provide tenant-specific configuration:

Later steps override earlier ones (step 5 is the final value). Environment-specificity is an attribute within the tenant tiers, not a separate “Environment Variable” tier.

Variable Types

Type	Description	Use Case
Template Variables	Defined by solution, values per tenant	Database connection strings
Common Variables	Free-form key-value pairs	Custom configuration

Database Schema

-- Core tenant table
CREATE TABLE tenants (
    id UUID PRIMARY KEY,
    name TEXT NOT NULL UNIQUE,
    description TEXT,
    logo_url TEXT,
    contact_email TEXT,
    created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP
);

-- Tenant-Solution-Environment junction
CREATE TABLE tenants_solutions_environments (
    id UUID PRIMARY KEY,
    tenant_id UUID NOT NULL REFERENCES tenants(id) ON DELETE CASCADE,
    solution_id UUID NOT NULL REFERENCES solutions(id) ON DELETE CASCADE,
    environment_id UUID NOT NULL REFERENCES environments(id) ON DELETE CASCADE,
    is_active BOOLEAN NOT NULL DEFAULT TRUE,
    created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
    UNIQUE (tenant_id, solution_id, environment_id)
);

-- Tenant-Target assignment
CREATE TABLE tenants_targets (
    id UUID PRIMARY KEY,
    tenant_id UUID NOT NULL REFERENCES tenants(id) ON DELETE CASCADE,
    target_id UUID NOT NULL REFERENCES targets(id) ON DELETE CASCADE,
    environment_id UUID REFERENCES environments(id) ON DELETE CASCADE,
    created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
    UNIQUE (tenant_id, target_id, environment_id)
);

API Overview

Endpoint	Method	Description
/api/v1/tenants	GET	List tenants
/api/v1/tenants	POST	Create tenant
/api/v1/tenants/{id}	GET	Get tenant details
/api/v1/tenants/{id}	PUT	Update tenant
/api/v1/tenants/{id}	DELETE	Delete tenant
/api/v1/tenants/{id}/solutions	GET	List tenant solutions
/api/v1/tenants/{id}/solutions	POST	Attach solution
/api/v1/tenants/{id}/targets	GET	List tenant targets
/api/v1/tenants/{id}/targets	POST	Attach target
/api/v1/tenants/{id}/variables	GET	List tenant variables
/api/v1/tenants/{id}/variables	POST	Set variable
/api/v1/tenants/{id}/deployments	GET	List tenant deployments

Permissions

Action	Required Permission
List tenants	tenants:read
Create tenant	tenants:create
Update tenant	tenants:update
Delete tenant	tenants:delete
Manage solutions	tenants:manage_solutions
Manage targets	tenants:manage_targets
Manage variables	tenants:manage_variables
Manage tags	tenants:manage_tags

Use Cases

SaaS Provider

Host multiple customers on shared infrastructure:

├── Tenant: Customer A
│   ├── Production deployment targets
│   ├── Customer-specific variables
│   └── Isolated audit trail
│
├── Tenant: Customer B
│   ├── Production deployment targets
│   ├── Customer-specific variables
│   └── Isolated audit trail

Enterprise Teams

Separate organizational units:

├── Tenant: Engineering
│   ├── Dev/Staging environments
│   └── Engineering targets
│
├── Tenant: Operations
│   ├── Production environments
│   └── Production targets

Development vs Production

Isolate environments:

├── Tenant: Development
│   ├── Development solutions
│   └── Non-production targets
│
├── Tenant: Production
│   ├── Promoted solutions
│   └── Production targets

Best Practices

Naming Conventions

Resource	Convention	Example
Tenant name	Organization/team name	acme-corp, engineering
Variables	Lowercase with underscores	database_connection_string
Tags	Descriptive key:value	team:platform, env:production

Security

1. Assign users to tenants - Don’t create platform-level users for tenant access
2. Use SSO with tenant mapping - Configure IdP groups per tenant
3. Audit regularly - Review tenant access and deployments
4. Minimize cross-tenant access - Keep platform admins to a minimum

Operations

1. Document tenant structure - Maintain tenant inventory
2. Standardize entitlements - Create consistent solution-environment patterns
3. Monitor per-tenant - Track deployment success rates by tenant
4. Plan capacity - Consider tenant growth in infrastructure planning

Next Steps

• Tenant Creation - Create and configure tenants
• Data Isolation - Security and isolation model
• Tenant Administration - Day-to-day management