Monopam serves several customers from one platform. A service provider (MSP or MSSP) runs a main tenant for its own staff and one tenant per customer, controls which of its people may enter which customer, and can make its own vault items usable in a customer tenant without copying the secret. This guide explains the tenancy models and how to operate them.
|
Applies to |
Who can do this |
|---|---|
|
Monopam v2026.10 |
Super administrators of the main (default) tenant. The Tenants page exists only when the installation runs with |
Three ways to host a customer
|
|
Shared tenant |
Dedicated-database tenant |
Remote tenant |
|---|---|---|---|
|
Runs on |
The provider's installation |
The provider's installation |
The customer's own installation, in the customer's environment |
|
Customer data |
In the installation database, separated by tenant |
In a database of its own (PostgreSQL or SQL Server, same type as the installation) |
In the customer's own database; nothing at the provider |
|
Database credentials |
Provider |
Provider (stored encrypted, never shown again) |
Customer only |
|
Connection |
None needed |
Provider's servers open the customer database |
One outbound WebSocket from the customer to the provider; no inbound rule at the customer |
|
Backup and maintenance window |
With the installation |
Per tenant database |
The customer's own |
|
Who approves provider staff |
Provider |
Provider |
The customer approves each person and chooses what they see |
|
Fits |
Small customers |
Customers that need their own backup, placement or maintenance window |
Customers that keep their data, keys and database to themselves (for example regulated industries) |
How tenants are kept apart
-
The request host decides the tenant. Every tenant has its own host names; a request for an address that belongs to no tenant reaches no tenant. A tenant cannot be chosen with a request header.
-
A session belongs to one tenant. A sign-in cookie issued for one tenant is refused on every other tenant's address.
-
Provider staff enter only with a grant. A grant names one tenant, one role and the tenant policies that decide what the person sees. Suspending or revoking it ends the open session within seconds.
-
A remote tenant never accepts an inbound connection. Every message on its link is signed, time-stamped and accepted once; the customer can disconnect the provider at any moment.
-
Secrets of shared vault items stay with the provider. The customer tenant reads them at the moment of use and, by default, cannot display or export them.
In this guide
-
Tenants and tenant databases: create a tenant, choose where its data lives, map its addresses and follow its setup.
-
Remote tenants: connect a customer-hosted installation and hand the customer its deployment files.
-
Provider access: let provider staff work inside customer tenants with roles, policies and end dates.
-
Shared vault items: use one provider-managed account in many customer tenants.
-
Multi-server deployment and tenant isolation: run tenants on separate application servers.