Skip to main content
Automatic provisioning is driven by a tenant’s service registration. It can create the backing resources declared for that service, record their credentials, and run the product-specific initialization needed before the service accepts traffic. The exact resources and lifecycle are service-specific. Do not assume that every multi-tenant product provisions PostgreSQL, MongoDB, RabbitMQ, or migrations in the same way.

​
Lifecycle

  1. Create a tenant identity. The tenant exists before a product service is attached to it.
  2. Register a tenant service. The registration identifies the product service, its environment, isolation mode, and connection/provisioning information. Tenant Manager uses dedicated and shared for the storage modes described elsewhere as DATABASE and SCHEMA.
  3. Provision supported backing resources. Tenant Manager invokes the adapters required by the registered service and mode.
  4. Initialize the product. Schema migrations and readiness work follow that product’s own provisioning contract.
  5. Operate the service. The product uses its own authentication and routing contract to serve the tenant.
A successful tenant-service registration is not a blanket guarantee that every product’s database, broker, and migration lifecycle is identical. Verify the product-specific provisioning requirements before onboarding production tenants.

​
Storage resources

​
Base URLs for machine-to-machine credentials

A tenant service can declare an optional baseUrls map for the staging and production environments. Tenant Manager selects the URL for the tenant’s environment as targetBaseUrl when it creates, rotates, or recreates a machine-to-machine credential. Each value must be an absolute HTTP or HTTPS URL with a host. It cannot include a path other than /, query string, fragment, or user credentials. HTTPS is required outside Kubernetes cluster-local services (*.svc.cluster.local) and local development (localhost or 127.0.0.1). Updating baseUrls replaces the service’s map. It does not rewrite existing machine-to-machine credentials; rotate or recreate the credential when the endpoint must change.

​
Operator checks

Before registering a production tenant service:
  • Confirm that the product and entitlement support multi-tenancy.
  • Select dedicated or shared according to the product’s supported storage configuration.
  • Validate the backing resources, credentials, network path, and product migration process.
  • Register baseUrls only for endpoint URLs that are valid for the tenant environment.
  • Test provisioning, authentication, and rollback using the product’s own operational guide.

Multi-tenancy

How products scope requests and how PostgreSQL isolation modes differ.

Use cases

Choosing dedicated or shared PostgreSQL isolation for a service.