Multi-server deployment and tenant isolation

One Monopam installation (one installation database, one cache, one vault key) can run on several application servers. Each server answers requests for a chosen set of tenants and runs scheduled work for a chosen set of tenants, so a large customer can get a server of its own.

Applies to

Who can do this

Monopam v2026.10

Whoever operates the deployment's environment. There is no in-app setting; the values are environment variables.

Settings

Variable

Default

Meaning

MONOPAM_SERVED_TENANTS

* (all)

Comma-separated tenant names this server answers requests for. Other tenants' addresses get the tenant-not-found page on this server.

MONOPAM_JOB_TENANTS

Same as served

Comma-separated tenant names whose scheduled work (rotation, discovery, user synchronisation, certificate jobs, alerts, queued jobs) runs on this server. * means all.

MONOPAM_VAULT_KEY

Built-in key

Must be identical on every application server and every gateway.

MONOPAM_TENANT_MANAGEMENT

Off

true enables the Tenants page on the default tenant.

Example

Bash
# main server: answers for every tenant, runs scheduled work only for its own
MONOPAM_SERVED_TENANTS=*
MONOPAM_JOB_TENANTS=default

# customer server: answers and runs scheduled work for one tenant
MONOPAM_SERVED_TENANTS=customer-a
MONOPAM_JOB_TENANTS=customer-a

Point the customer's DNS name at the customer server; the host mapping on the tenant's Hosts tab stays the same. A tenant with a dedicated database is best served by its own server.

Isolation guarantees

  • The tenant of a request is derived from the request's host and port only. A request header cannot select a tenant.

  • A session is bound to the tenant it was issued for; using its cookie on another tenant's address is refused and signs the user out.

  • Cookie protection keys are stored in the database, so sessions survive restarts and are readable by every server.

  • Start-up migration and seeding are serialised across servers with a lock in the cache.

Rules for operators

  • List every tenant in exactly one server's MONOPAM_JOB_TENANTS. A tenant listed on two servers runs its rotations, alerts and synchronisations twice.

  • On a fresh database, start the main server first: it creates the default tenant.

  • Every gateway is registered to one tenant and calls that tenant's address; the address must be served by the server it reaches.

  • A tenant's failure inside one scheduled run can delay the other tenants of that run until the next one; shared tenants run before dedicated ones.

  • Service Provider Guide

  • Tenants and tenant databases

  • Vault encryption key

  • Network ports and firewall rules