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

# Enabling Access Manager

> Activate Access Manager across Lerian products — set the Auth environment variables in each `.env` so your services start enforcing access.

[Installing Access Manager](/en/platform/access-manager/installing-access-manager) isn't enough on its own. To start enforcing access, you turn it on in each product by setting the Auth variables in the `.env` file of **any Lerian product or plugin** where you want it active.

<Note>
  Enabling Access Manager only turns on authorization enforcement in a product or plugin. Access data such as users, groups, applications, providers, roles, and permissions is managed separately through Access Manager.
</Note>

Every protected product must enable enforcement and point to Auth. The address variable is not the same in every repository, so use the variable expected by the product you are configuring:

<CodeGroup>
  ```text Text theme={null}
  # Most products and plugins
  PLUGIN_AUTH_ENABLED=true
  PLUGIN_AUTH_ADDRESS=http://plugin-auth:4000
  ```

  ```text Text theme={null}
  # Midaz Ledger and Pix Direct JD
  PLUGIN_AUTH_ENABLED=true
  PLUGIN_AUTH_HOST=http://plugin-auth:4000
  ```
</CodeGroup>

For BYOC multi-tenant deployments, enable multi-tenant mode in Access Manager and in each protected product that participates in tenant isolation:

<CodeGroup>
  ```text Text theme={null}
  # MULTI-TENANT CONFIG
  MULTI_TENANT_ENABLED=true
  ```
</CodeGroup>

In single-tenant deployments, Access Manager uses the configured default organization. In multi-tenant deployments, tenant scope is resolved from trusted token and application context.

<Danger>
  Once **Access Manager** is enabled, protected API requests must include an `Authorization` header with a valid **Bearer access token**.

  Without this header, protected requests will be rejected, even for endpoints that were previously accessible without authentication.

  [**Learn how to generate and use access tokens.**](/en/platform/access-manager/using-access-manager)
</Danger>

## Where to update

***

You'll find the relevant `.env` files in these locations:

* **Midaz**
  * `/midaz/components/ledger` uses `PLUGIN_AUTH_HOST`. CRM and Fees run inside the ledger binary and follow this setting.
  * `/midaz/components/tracer` uses `PLUGIN_AUTH_ADDRESS`
* **Other products and plugins**
  * Use the `.env` file in the product or plugin root, or in the component directory when the repository is split into components.
  * Reporter, Flowker, Bank Transfer, Pix Indirect BTG, and Fetcher use `PLUGIN_AUTH_ADDRESS`.
  * Pix Direct JD uses `PLUGIN_AUTH_HOST`.

<Tip>
  If you can't see the files, adjust your system settings to show hidden files. `.env` files are often hidden by default.
</Tip>

## Rebuild after changes

***

After updating the environment, rebuild your Docker images to apply the changes:

<Steps>
  <Step>
    In your terminal, go to the root of your project.
  </Step>

  <Step>
    If Docker is running, stop it:

    <CodeGroup>
      ```bash Bash theme={null}
      make down
      ```
    </CodeGroup>
  </Step>

  <Step>
    Then rebuild everything:

    <CodeGroup>
      ```bash Bash theme={null}
      make rebuild-up
      ```
    </CodeGroup>
  </Step>
</Steps>

## Deployment lifecycle

***

Access Manager setup has two phases:

* **Bootstrap** seeds a new environment with the base organizations, roles, groups, applications, and permission sets required by the platform.
* **Operation** starts after the environment is running. From that point on, manage access through the Identity APIs or Lerian Console.

Use the operational APIs for user access, group assignment, application credentials, providers, and MFA. Don't change a running environment by editing bootstrap seed files.

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