Stop rebuilding the foundation
Start with tenant routing, identity, permissions, data boundaries, branding, modules, support and audit connected by one operating model.
OpenTenant gives agencies and SaaS teams the shared parts every multi-tenant product needs—identity, isolated data, branding, modules, support and audit—while each client keeps its own product experience.
Pre-1.0 and transparent by design. See what is implemented, what has been tested in development, and what still needs production approval. GitHub access is currently restricted while the public OSS release is prepared.
One installation
Owner control plane
Tenant 01
Own brand · people · modules · data
Tenant 02
Own brand · people · modules · data
Tenant 03
Own brand · people · modules · data
01 / Why OpenTenant
A new client or SaaS product quickly becomes a second platform to maintain. The work that should have been shared becomes the work that slows every release.
Start with tenant routing, identity, permissions, data boundaries, branding, modules, support and audit connected by one operating model.
Share platform capabilities without forcing every tenant into the same brand, domain, navigation, modules or operating rules.
Put identity, data access, provider integrations and managed support in explicit architectural contracts instead of scattered conventions.
02 / What it handles
OpenTenant treats the installation, each tenant and every module as different scopes—so shared infrastructure does not erase product difference.
An agency, SaaS company or enterprise team creates and configures tenant organizations directly. There is no second client-registration system to operate.
Requests resolve to one tenant before identity, data or module access. Unknown or contradictory context fails closed instead of guessing.
Each tenant can carry its own brand, domains, people, navigation, enabled modules and data plane while sharing the same platform core.
Managed support is designed for practical routine configuration while keeping the real operator visible and sensitive actions more tightly governed.
Tenant developers can begin with a shadcn-ready UI starter. Choosing a component never silently grants database access; capabilities stay separate.
A deployment selects WorkOS or Clerk for identity. Vercel and Neon are the current reference targets, behind OpenTenant-owned contracts.
03 / AI and module development
OpenTenant treats the agent that helps build a module, the knowledge an AI can retrieve, and operator diagnostics as separate product surfaces. The current foundations are designed so each can carry its own identity, permissions, data scope and audit evidence as it becomes available.
Developer MCP
A governed, agent-friendly path for discovering platform contracts, scaffolding tenant-private modules, running isolated builds and previews, and collecting approval evidence. The safety foundation exists; successful tool routes are not exposed yet.
Knowledge / Brain
A tenant-local knowledge-module example for provenance, source connectors, retrieval, cited decisions, and governed MCP access. The contracts and denial-first gateway are scaffolded; ingestion, search, and promotion remain follow-on work.
Brain MCP boundary
Tool discovery is permission-gated. Identity is required. Promotion is denied in the current scaffold, and search execution is not yet implemented.
Knowledge / Brain pattern
Designed to turn approved Slack, Gmail, Drive, and Calendar signals into tenant-local context with provenance, citations, human promotion, and a permission-bound MCP surface.
Assessment example
Combine deterministic scoring and exports with optional model readouts, while keeping the core workflow usable without an AI provider key.
Developer MCP direction
Let an approved developer or coding agent shape a tenant-private operations module, preview it in isolation, and request only the data capabilities the workflow needs.
Developer MCP · foundation only
Is designed to build and validate tenant-private module artifacts; successful tool routes are not exposed yet.
Brain MCP · scaffold
Is designed to retrieve tenant knowledge through a separate governed surface; search execution is not implemented yet.
Vercel MCP
Helps a human operator inspect deployments and logs; it has no tenant authority.
04 / How it works
Move from shared source to a distinct tenant product in four understandable steps, with implementation choices contained behind stable contracts.
Use the platform shell, contracts, migrations, examples and verification suite as the installation foundation.
Choose WorkOS or Clerk for hosted identity, Vercel for the app and Neon PostgreSQL for tenant data.
Configure brand, domains, members, navigation, modules and data location. A brand URL is optional; without one, values begin empty.
Add native, installation-owned or tenant-private modules at explicit ownership and data boundaries.
05 / Built for operators
The model works whether the installation owner is an agency, a focused SaaS team or an enterprise platform group.
Operate a central owner console while each client installation keeps its own brand, tenant mix and product experience.
Begin with a serious multi-tenant model and spend scarce product time on the workflow customers are actually buying.
Standardize shared foundations without erasing the policies, modules and data boundaries that make business units different.
06 / Current reference stack
These providers are implementation choices, not the product domain model. Their SDKs stay at adapter or composition boundaries, leaving room for future alternatives.
07 / Inspectable progress
OpenTenant is pre-1.0. The repository separates code that exists, provider behavior tested with synthetic development data, foundations intentionally not exposed yet, and production decisions that still require an owner.
Capabilities source · access required523
automated tests in the verified project snapshot
183
live PostgreSQL isolation and immutability checks
2
identity choices behind one internal contract
0
successful Developer MCP tool routes claimed as shipped
08 / Questions
The repository is the source of truth. These answers describe the current intent and maturity without turning planned work into a product claim.
Build the client product. Reuse the platform work.
Review the architecture, verification evidence and open decisions, then decide whether OpenTenant fits your next multi-tenant product.