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

# Installing Access Manager

> Prepare your environment, deploy the Auth and Identity services, and get Access Manager ready before any Lerian product enforces access.

Installing Access Manager means getting the **Auth** and **Identity** services running, connected to their dependencies, and ready to answer access decisions. It's the step that has to happen *before* any Lerian product can enforce authentication or permissions.

This guide is written for operators who are setting up the environment. It explains what installation actually covers, what you need in place, and the order in which to bring things up. For the Helm chart commands and chart-level configuration, follow the [Access Manager via Helm](/en/platform/helm/access-manager/access-manager-helm) page.

## Prerequisites

***

You don't need to be deep in Kubernetes to plan an installation, but you do need a clear picture of the pieces involved. Treat the list below as a checklist before you start.

### License

Access Manager is an Enterprise feature and requires a valid Lerian license configuration. The services apply license checks through HTTP middleware, so validate the license before enabling protected products. See the [License documentation](/en/reference/lerians-license) for details. If you don't have a license yet, [get in touch with our team](https://lerian.studio/contact).

### Deployment model

Decide how you're going to run Access Manager. The choice shapes tenant resolution, Casdoor configuration, and a few operational defaults later on.

* **SaaS** - Lerian runs the platform; access flows are tenant-scoped from trusted JWT claims.
* **BYOC multi-tenant** - You run Access Manager, and tenant context comes from trusted token claims, never from request payloads or headers.
* **BYOC single-tenant** - You run Access Manager against a configured default organization and Casdoor identity backend.

If you're not sure which model applies, confirm with your Lerian contact before installing.

### Auth service

The runtime side of Access Manager: it issues and refreshes tokens, validates sessions, checks permissions, handles logout and user info, and runs MFA challenges. Auth needs to be reachable from every protected Lerian product over the network.

### Identity service

The data side of Access Manager: users, groups, applications, communication providers, application-provider links, and MFA configuration. Identity is the management surface. Both Identity and Auth connect to the configured Casdoor backend: Identity manages identity data through it, while Auth uses its own connection for tokens, MFA, and authorization decisions.

### Identity backend

Access Manager uses a configured Casdoor backend for identity storage. Casdoor persists its identity data in the configured PostgreSQL database; PostgreSQL backs Casdoor, it does not replace it. In SaaS and most BYOC deployments, the backend comes pre-configured. For a BYOC deployment, configure that Casdoor backend for your environment; Access Manager does not connect directly to arbitrary identity-provider APIs.

### Data and cache services

* A **PostgreSQL** instance as the backing database for Casdoor-managed identity data.
* A **Valkey** cache for token, permission, and MFA-related operations.

Both must be provisioned and reachable before Auth and Identity start. Sizing and high-availability decisions depend on your deployment model.

### Product connectivity

Plan the network paths now so you're not debugging them later:

* Protected products must reach **Auth** over the network.
* Administrators (and any back-office tooling) must reach **Identity** to manage users, groups, applications, and providers.
* Neither service should be exposed publicly without the appropriate ingress controls.

### Environment and bootstrap data

A fresh single-tenant environment seeds base access data, including its organization, built-in roles, groups, applications, and permission sets, once at startup. Multi-tenant bootstrap prepares shared certificate material only; tenant organizations and access data are created after the tenant exists. This is the **bootstrap** layer. After the environment is running, day-to-day changes happen through the Identity APIs or Lerian Console, not by editing bootstrap data.

<Warning>
  Bootstrap seed data is only applied during initial environment setup. Changes to built-in resources, actions, roles, groups, applications, or permission sets in an existing environment must be delivered through controlled platform updates, such as migrations or an idempotent reconciler.
</Warning>

## Installation flow

***

Follow these steps in order. Each one builds on the previous one, and skipping ahead is the most common cause of avoidable trouble later.

<Steps>
  <Step title="Choose your deployment model">
    Pick SaaS, BYOC multi-tenant, or BYOC single-tenant and confirm any model-specific decisions with your Lerian contact: tenant strategy, Casdoor configuration, and licensing scope. Write this down because every later step refers back to it.
  </Step>

  <Step title="Prepare dependencies">
    Provision the supporting infrastructure so Auth and Identity have everything they need at startup:

    * a valid Lerian license configured for the environment;
    * a PostgreSQL instance to back Casdoor-managed identity data;
    * a Valkey cache for tokens, permissions, and MFA;
    * the configured Casdoor identity backend;
    * network paths between Access Manager, its dependencies, and the products that will eventually enforce access.

    Don't move on until each dependency is reachable from where Access Manager will run.
  </Step>

  <Step title="Deploy Auth and Identity">
    Install the Access Manager services into your environment. For Kubernetes, the supported path is the Helm chart. See [Access Manager via Helm](/en/platform/helm/access-manager/access-manager-helm) for chart versions, OCI registry, and the exact `helm install` command.

    If you only need to evaluate Access Manager locally before a real deployment, use the source repository's `make up` command. It builds and starts the Access Manager stack. Use the lifecycle commands documented by the repository revision you run.
  </Step>

  <Step title="Bootstrap base access data">
    In single-tenant mode, first startup seeds the base organization, built-in roles, groups, applications, and permission sets that the platform relies on. In multi-tenant mode, bootstrap does not seed tenant organizations or access data; create that data after tenant creation. Let bootstrap finish before pointing any product at the services.

    From this point on, treat bootstrap data as read-only. Manage everyday access through the Identity APIs or Lerian Console.
  </Step>

  <Step title="Validate the services">
    Confirm that the installation is healthy *before* any product depends on it:

    * Auth and Identity report healthy and are reachable from the products that will use them.
    * PostgreSQL (Casdoor's backing database) and Valkey are connected and responsive.
    * The Casdoor identity backend is configured and reachable.
    * A test token request succeeds against Auth, and a basic Identity call (for example, [List Groups](/en/reference/access-manager/list-groups)) succeeds for the selected deployment mode. In multi-tenant mode, create tenant access data before expecting groups to be returned.

    If anything in this list fails, fix it here. Don't enable products on top of an unhealthy install.
  </Step>

  <Step title="Enable protected products">
    Once installation is validated, turn enforcement on inside each Lerian product or plugin by setting the Auth variables in its `.env`. The full per-product configuration, including multi-tenant settings, lives in [Enabling Access Manager](/en/platform/access-manager/enabling-access-manager).
  </Step>

  <Step title="Use Access Manager">
    With installation done and products enforcing access, move on to day-to-day operation: requesting tokens, managing users, groups, and applications, configuring MFA, and calling protected APIs. Start with [Using Access Manager](/en/platform/access-manager/using-access-manager) for the API workflow, or [Access Manager via Lerian Console](/en/platform/access-manager/using-access-manager-with-midaz-console) for the visual flow.
  </Step>
</Steps>

<Tip>
  Treat installation as its own milestone. Auth and Identity should be deployed, healthy, and validated *before* you flip any product into enforcement mode. That single habit avoids most first-day incidents.
</Tip>

## Next steps

***

* [Enabling Access Manager](/en/platform/access-manager/enabling-access-manager) - turn on enforcement in each Lerian product.
* [Using Access Manager](/en/platform/access-manager/using-access-manager) - request tokens, manage users and applications, configure MFA.
* [Access Manager via Helm](/en/platform/helm/access-manager/access-manager-helm) - chart versions, OCI registry, and installation commands.
* [How Access Manager works](/en/platform/access-manager/am-components) - a closer look at Auth, Identity, and product-level enforcement.