Another app. Another login. Another gap.
Every portal, internal tool and vibe-coded experiment arrives with its own sign-in, its own branding and nobody watching who can reach what. OpenTenant is the foundation they should all have been built on: one identity model, isolated data and branding per client, a built-in help desk, and an audit trail across all of it. New modules are designed to be built through an MCP interface, inheriting every one of those on day one.
One installation
Many tenants
- Tenant 01Own brand, own domain, own features
- Tenant 02Own brand, own domain, own features
- Tenant 03Own brand, own domain, own features
- Add another whenever the business needs one
Separate data · separate sign-in · one codebase
Nobody set out to build fourteen half-governed apps.
It happens one urgent request at a time. A portal for one client, an internal tool for one team, a prototype that quietly became load-bearing. Each ships with its own sign-in, its own idea of the brand, and no shared answer to who can see what. Here is what you get instead, on day one.
- Your console
Set up clients from one place
You create and configure every client organisation yourself. There is no second registration app to build, host and keep in sync.
- Working today
- Isolation
A request belongs to one client, or it stops
Every request resolves to a single client before it reaches sign-in, data or a feature. Missing or contradictory context fails closed rather than guessing.
- Working today
- Tenant access
People see only the clients they can enter
After sign-in, the launcher shows only active client memberships. A launch link exists only for an active, verified OpenTenant domain, and the destination is resolved from the hostname, not a header, cookie, query string, form value or provider ID.
- Working today
- Branding
Each client gets a product, not a reskin
Own brand, own domains, own people, own navigation, own features, own database. All of it running on the same platform code.
- Working today
- Support
Support staff without shared logins
Your team can work inside a client’s account while the audit trail keeps naming the actual person, with a reason recorded and the riskier actions held behind tighter checks.
- Working today
- Activity
Tenant admins can see recent changes
Owners and admins get a bounded timeline for their active client. It shows approved summaries, actor categories and safe resource labels; raw audit detail, secrets, hidden actions and another client’s events stay out.
- Working today
- Admission
Limits agree across every running process
Assessment readouts, telemetry and module access share transactional PostgreSQL limits, leases and idempotent retries. A replay cannot repeat the original side effect, and failed or expired work releases its capacity.
- Working today
- Usage evidence
Usage is exact before anyone prices it
Immutable client-scoped events keep occurrence and recording time separate. Retries resolve to one identity, corrections append instead of rewriting history, and pricing and billing remain a separate owner decision.
- Working today
- MCP interface
A new feature does not come with the database
The Developer MCP foundation now defines exact modern discovery, private permission-filtered tool lists and authorization that is checked again on every call. Picking an interface never grants data access; resources remain a separate, explicit decision.
- Security foundation built · tool routes closed
- Authentication
Pick WorkOS or Clerk. Same code either way
Choose one at setup and both land on the same internal model for people, roles and permissions. Your own code never learns which one you picked.
- Working today
One instance. Every client.
Fourteen apps means fourteen deploys, fourteen dependency bumps and fourteen places a vulnerability can sit unnoticed. One multi-tenant instance means one of each.
- Patch once, not fourteen times
- A fix to shared code reaches every client the moment you deploy. Nobody is left running last quarter’s version because their fork never got merged.
- Add a client without adding infrastructure
- A new tenant is a record in your console. Not another app to host, monitor, back up, secure and pay for.
- Configure instead of fork
- Brand, domains, navigation and enabled features are settings. Two clients can look and behave nothing alike without becoming two codebases.
- One of everything to run
- One deploy pipeline, one database platform, one identity model, one audit trail. Your team’s attention goes to the product instead of the estate.
A help desk that already knows the client.
Support is built in, not bolted on. Your client’s people raise a ticket from inside their own branded product, and it lands in one queue for your team with the client, the history and the SLA clock already attached.
Response and resolution targets, support hours, warning thresholds and pause rules come from your defaults, with per-client overrides where you allow them. Tickets are written to the client’s own database, so a delivery hiccup can never lose one.
An AI agent works the queue before your team does. It reads the ticket, reproduces the problem as a failing test, writes a candidate fix in a sandbox and, where you allow it, ships that fix and closes the ticket. You set how far it may go, per client, and it starts at suggestions only.
It can never touch sign-in, permissions, your database schema or your dependencies, and the ticket text itself never reaches the part that writes code. A customer cannot talk it into anything, because the agent holding that authority never reads what they wrote.
How support worksSupport agent not built yet
Your client sees
- A Get help button, in the client’s own branding
- My tickets for members, a full queue for their admins
- Public replies, attachments, resolution and a CSAT score
- Notification preferences, and mute on a single ticket
Your team sees
- All, Unassigned, Mine, Escalated and SLA risk queues
- Filter by client, status, priority, category, tag or assignee
- Public conversation and internal notes, composed separately
- Enter the client’s account without losing the ticket
Describe a feature. Get one that already belongs.
Modules are built through an MCP interface, by your developers or by a coding agent working on their behalf. The point is not that an agent can write code. It is what the code lands in.
A new module arrives already knowing who the user is, which client they belong to, what they are allowed to do, and which slice of data it may read. Sign-in, groups, permissions, support and audit are the platform’s job, not the module’s. Nobody rebuilds them per feature, and nobody forgets one.
The shipped foundation follows the current stable MCP 2026-07-28 contract, keeps discovery private to effective authority, and fails closed when membership, consent, token authority or resource access is missing or stale. High-risk actions are checked again immediately before allow.
This is a security foundation, not an open build agent: there are still zero successful Developer MCP tool routes. Sandbox execution, publication and real client operations remain behind later review.
How the build agent worksFoundation verified · tool routes not open yet
Every module inherits
- Sign-in, through your chosen provider
- Users, groups, roles and permissions
- A data boundary scoped to one client
- The audit trail, with no extra wiring
Already enforced in the foundation
- 1Discover only the tools its approved authority allows
- 2Recheck membership, client consent and token authority on every call
- 3Resolve resource access without trusting a client-supplied tenant
- 4Revalidate high-risk actions immediately before they can proceed
Three surfaces. Only one gets near client data.
Each client’s assistant answers only from that client’s own material, with provenance kept and citations attached. The build agent never sees data at all. Deploy tooling sits outside entirely. The names matter less than the line each one is allowed to stand on.
Deploy tooling
Lets you read deploy logs when something breaks.
Outside
Never sees client data
The build agent
Writes and checks a feature for one client.
Outside
Builds up to the line, never over it
Tool routes not open yet
The knowledge assistant
Answers from one client’s material, for that client.
On the line
Crosses only with permission, refuses otherwise
Search not wired up yet
Four steps to a client’s own product.
From cloning the repository to a client with their own domain, their own brand and their own feature set.
- 1
Start from the platform
The shell, the contracts, the migrations, the worked examples and the test suite all come with it.
- 2
Pick your auth provider
WorkOS or Clerk, chosen once at setup. Vercel and Neon are already wired for hosting and data.
- 3
Set up each client
Brand, domains, members, navigation, features and where the data lives. Point it at a brand URL and review the proposed values; skip that and you start blank.
- 4
Build the part they pay for
Add features owned by the platform, by you, or by one client alone, with the data boundary stated up front.
The same four steps whether you are an agency running client products, a SaaS team wanting real multi-tenancy from the first commit, or a platform team keeping each business unit’s policies and data its own.
Your SOC 2 evidence, collected as you go.
Gathering control evidence is the part of a SOC 2 programme nobody budgets for. OpenTenant writes it as the work happens, rather than leaving you to reconstruct a year of it from screenshots.
Every record carries the real person behind the action, the reason given, the authorisation decision and the policy version it was judged against, plus a digest chained to the record before it. Export is explicit, bounded and redacted. It is never a running feed of your clients’ content.
We generate the evidence. Your auditor still writes the report: certification needs your controls, your operating period and their opinion, and no amount of software substitutes for that.
What gets recordedExport slice and Vanta connector in development
What the evidence trail covers
- Access, role and permission changes, plus periodic review
- Client, domain, brand, feature and integration changes
- Code review, release, rollback and emergency change
- Backup, restore, incident and support SLA health
- Vulnerability, dependency, secret and sandbox checks
- Credential creation, use, rotation and revocation
- Data location, retention, export, deletion and restore drills
Nothing exotic in the stack.
These are choices, not the architecture. Each provider sits behind an adapter, so replacing one later is a contained job rather than a rewrite of your product.
Numbers pinned to a commit.
OpenTenant is pre-1.0 and under active development. The repository keeps four things apart: code that exists, behaviour tested against development data, work that is designed but deliberately not switched on, and decisions still waiting on an owner.
- 957
- automated tests in the verified build
- 183
- live checks that one client cannot read another’s data
- 2
- sign-in providers behind one internal contract
- 0
- customer records this project has ever touched
Engineering checks from the verified build, not customers or usage. The test and isolation counters are deliberately conservative, and every provider result so far comes from synthetic development data.
The governed local queue is complete: 37 of 37 non-owner tasks are verified. Four owner decisions still gate Slack activation, the first callable Developer MCP route, compliance scope and commercial billing.
The awkward questions, answered.
The repository is the real answer to all of these, once access opens. Here is the short version, with nothing planned dressed up as finished.
Judge the architecture before you trust it.
The architecture, the test evidence and the decisions still open are all in the repository. Have a look, then decide whether this is the foundation for your next client product.
Source access is restricted while the public open-source release is prepared.