Skip to main content
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 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 for details. If you don’t have a license yet, get in touch with our team.

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

​
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.
1

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

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

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

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

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) 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.
6

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

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 for the API workflow, or Access Manager via Lerian Console for the visual flow.
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.

​
Next steps