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.