Skip to main content

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 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 to run. Without it, the services will not start. 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, 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.
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, identity provider, 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 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.
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, you can run the plugins with the plugins-docker-compose repository instead.
4

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.
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 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) returns the seeded data.
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