Skip to main content

Unomi 3 · Multi-tenancy

Multi-tenancy in Apache Unomi 3

A major platform refactoring — not a bolt-on flag. Isolate customer spaces with API keys on one cluster.

Among the Unomi 3.1 changes, multi-tenancy stands out for scope and effort. The work cut across persistence, APIs, security, schemas, rules, segments, events, and operations so a single Unomi cluster can host many isolated tenants.

This is foundational for SaaS control planes and agencies running many customer spaces — without bolting on a separate Unomi per customer.

Multi-tenancy architecture with API keys and isolated tenants

What is isolated

  • Profiles, events, and sessions
  • Segments, scores, and rules
  • Schemas and definitions scoped per tenant

How access works

  • Public and private API keys resolve requests to a tenant
  • Administrative vs public traffic can be separated by key type
  • Native 3.1 auth expects tenant API keys; V2 compatibility mode helps phase older clients

Operations

  • Tenant usage metrics for upstream control planes
  • Event retention / purge APIs for lifecycle management
  • Works with Elasticsearch or OpenSearch persistence

Why it matters

Multi-tenancy was one of the largest engineering investments in Unomi 3 — a deep refactor so isolation is correct end-to-end, not a superficial namespace prefix. Pair it with the rest of the Unomi 3 story for the platform and quality context.

Open the manual Unomi 3 intro Migration guide

← All posts