> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.

# Automatic provisioning

> How Tenant Manager provisions supported tenant services and validates the service endpoints used for machine-to-machine credentials.

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.

<Note>
  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.
</Note>

## Storage resources

***

| Resource        | Tenant Manager behavior                                                                                                                               |
| :-------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------- |
| **PostgreSQL**  | Uses a dedicated database in `dedicated` mode or a tenant schema in a shared database in `shared` mode.                                               |
| **MongoDB**     | Uses a tenant database in `dedicated` mode or a tenant collection prefix in `shared` mode.                                                            |
| **RabbitMQ**    | Provisions mode-specific messaging resources; do not rely on a universal vhost or queue naming convention.                                            |
| **Credentials** | Service credentials are stored and resolved through the registered service's credential path. Treat rotation and access controls as service-specific. |

## 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.

## Related pages

***

<CardGroup cols={2}>
  <Card title="Multi-tenancy" icon="layer-group" href="/en/multi-tenancy" cta="See the overview">
    How products scope requests and how PostgreSQL isolation modes differ.
  </Card>

  <Card title="Use cases" icon="lightbulb" href="/en/multi-tenancy/use-cases" cta="See examples">
    Choosing dedicated or shared PostgreSQL isolation for a service.
  </Card>
</CardGroup>