Productify

Appearance

Multi-tenancy ​

Manager provides environment-based isolation through a Project → Tenant → Application hierarchy, allowing multiple deployment environments per project.

What is Multi-tenancy in Manager? ​

Manager uses tenants to represent different environments (dev, staging, production) within a project:

  • Environment isolation - Separate dev/staging/production environments
  • Independent configuration - Settings per environment
  • Resource separation - Applications deployed per tenant/environment
  • Access control - Users assigned to specific tenants

Hierarchy ​

Project (Product/Organization)
  └─ Tenant (Environment)
      └─ Application (Service)
          └─ Endpoint (Access Point)

Example Structure ​

Project: ACME Platform
  ├─ Tenant: Development
  │   ├─ Application: Portal Frontend
  │   ├─ Application: Portal API
  │   └─ Application: Mobile App
  ├─ Tenant: QA/Staging
  │   ├─ Application: Portal Frontend
  │   └─ Application: Portal API
  └─ Tenant: Production
      ├─ Application: Portal Frontend
      ├─ Application: Portal API
      └─ Application: Mobile App

Project: GlobalTech SaaS
  ├─ Tenant: Development
  │   └─ Application: Web App
  └─ Tenant: Production
      ├─ Application: Web App
      └─ Application: API Gateway

Data Isolation ​

Database Level ​

Each tenant's data is isolated at the database level:

  • Tenant ID in all records
  • Row-level security enforced by queries
  • No cross-tenant queries allowed
  • Audit trail per tenant

Application Level ​

Applications are tenant-aware:

  • Configuration scoped to tenant
  • Resources (files, media) separated
  • API requests filtered by tenant
  • Background jobs isolated

User Access ​

Users are explicitly assigned to tenants:

  • No default tenant access
  • Role-based permissions per tenant
  • Admin users can have multi-tenant access
  • Audit logs track tenant access

Configuration Inheritance ​

Settings cascade from tenant to application:

Three Layers ​

  1. Project Settings - Defaults for all tenants in the project
  2. Tenant Settings - Defaults for apps in the environment
  3. Application Settings - Specific to one app

Inheritance Rules ​

  • Applications inherit from tenant
  • Tenants inherit from project
  • More specific settings override general ones

Example ​

Project Level (ACME Platform):

json
{
  "theme": "corporate-blue",
  "locale": "en",
  "support_email": "support@acme.com"
}

Tenant Level (Production):

json
{
  "theme": "professional-dark",
  "features": ["analytics", "monitoring"]
}

Application Level (Portal Frontend):

json
{
  "locale": "es"
}

Effective Configuration:

json
{
  "theme": "professional-dark", // from Tenant
  "locale": "es", // from Application (override)
  "support_email": "support@acme.com", // from Project
  "features": ["analytics", "monitoring"] // from Tenant
}

Tenant Domains ​

Each tenant/environment can have domains for accessing its applications:

Managed Domains ​

Auto-generated by Manager per environment:

<tenant-slug>-<project-slug>.productify.dev

Custom Domains ​

Environment-specific domains:

dev.portal.acmecorp.com     # Development tenant
staging.portal.acmecorp.com # QA tenant
portal.acmecorp.com         # Production tenant

Use Cases ​

Multi-Environment Deployment ​

Separate development, staging, and production:

Project: E-commerce Platform
  ├─ Tenant: Development
  ├─ Tenant: QA/Staging
  └─ Tenant: Production

Benefits:

  • Isolated testing environments
  • Safe deployment pipeline
  • Production-like staging

Multi-Region Deployment ​

Geographic environments within a project:

Project: Global Service
  ├─ Tenant: US-East
  ├─ Tenant: EU-West
  └─ Tenant: Asia-Pacific

Each region operates independently with region-specific data.

Feature Branch Environments ​

Dynamic environments for development:

Project: Product Development
  ├─ Tenant: Main
  ├─ Tenant: Feature-Auth
  └─ Tenant: Feature-Payments

Test features in isolation before merging.

Customer-Specific Deployments ​

Dedicated environments per customer:

Project: SaaS Product
  ├─ Tenant: Customer-A-Prod
  ├─ Tenant: Customer-B-Prod
  └─ Tenant: Customer-C-Prod

Each customer gets dedicated infrastructure.

Best Practices ​

Project & Tenant Design ​

  1. One project per product/organization
  2. Create tenants for each environment (dev, staging, production)
  3. Use tenant types - Set type field: local, dev, qas (staging), run (production)
  4. Set project-level defaults for settings shared across environments

Security ​

  1. Isolate production data - Never share production tenant access with dev
  2. Verify tenant context in all operations
  3. Audit cross-tenant access attempts
  4. Regularly review user assignments

Performance ​

  1. Monitor per-tenant usage
  2. Set resource limits per tenant/environment
  3. Index by tenant ID for queries
  4. Consider tenant-based sharding for very large deployments

Migration ​

  1. Export tenant data separately
  2. Test migrations in staging environment
  3. Maintain tenant isolation during migration
  4. Document tenant-specific customizations

Tenant Administration ​

Creating Tenants ​

Tenants are created within a project. See Managing Tenants for detailed steps.

Tenant Types:

  • local - Local development
  • dev - Development environment
  • qas - QA/Staging environment
  • run - Production environment

User Assignment ​

Assign users to tenants with roles:

  1. Navigate to Tenant → Users tab
  2. Click Add User
  3. Select user and role
  4. Click Save

Tenant Settings ​

Configure tenant-wide defaults:

  1. Navigate to Tenant details
  2. Go to Settings tab
  3. Configure backend/frontend settings
  4. Save changes

Monitoring ​

Track tenant activity:

  • Application count
  • User count
  • Resource usage
  • Audit logs

Isolation Guarantees ​

What is Isolated ​

[OK] Database records - All tenant data separated [OK] Configuration - Settings per tenant [OK] User access - Explicit tenant assignment [OK] File storage - Tenant-specific directories [OK] Audit logs - Per-tenant activity tracking [OK] API access - Filtered by tenant context

What is Shared ​

🔄 Application code - Same codebase for all tenants 🔄 Infrastructure - Shared servers (unless dedicated) 🔄 Database instance - Same DB, different data 🔄 Cache layer - Shared with tenant key prefixes

Compliance & Data Residency ​

GDPR Compliance ​

  • Data isolation ensures tenant data separation
  • Audit logs track data access
  • Export capabilities for data portability
  • Deletion removes all tenant data

Data Residency ​

For region-specific requirements:

  1. Deploy Manager instance in required region
  2. Route tenant to region-specific instance
  3. Configure DNS for geographic routing

Troubleshooting ​

User Cannot Access Tenant ​

Reason: User not assigned to tenant

Solution:

  1. Navigate to Tenant → Users
  2. Add user with appropriate role

Data Appearing in Wrong Tenant ​

Critical Issue: Report immediately

Check:

  1. Verify tenant ID in database
  2. Check application code for tenant filtering
  3. Review audit logs for unauthorized access

Performance Issues for Specific Tenant ​

Debug:

  1. Check tenant's resource usage
  2. Review number of applications/endpoints
  3. Optimize queries with tenant ID
  4. Consider tenant isolation/sharding

See Also ​