> ## 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 to run. Without it, the services will not start. 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, identity provider 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. You may also keep your existing identity provider and use Access Manager for product-level authorization.

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; Auth reads from it to make decisions.

### Identity provider

Access Manager delegates identity storage to an identity provider. In SaaS and most BYOC deployments this comes pre-configured. In BYOC single-tenant deployments where you already operate your own provider, you can keep it and let Access Manager add product-level authorization on top.

### Data and cache services

* A **PostgreSQL** instance for identity data storage.
* 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 environment needs base access data, including organizations, built-in roles, groups, applications, and permission sets, seeded once at startup. 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, identity provider, 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 for identity data;
    * a Valkey cache for tokens, permissions, and MFA;
    * the identity provider you intend to use (managed or your own);
    * 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, you can run the plugins with the [plugins-docker-compose repository](https://github.com/LerianStudio/plugins-docker-compose) instead.
  </Step>

  <Step title="Bootstrap base access data">
    On first startup, Access Manager seeds the environment with the base organizations, built-in roles, groups, applications, and permission sets that the platform relies on. 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 and Valkey are connected and responsive.
    * The identity provider 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)) returns the seeded data.

    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.