Auth

Self-Hosting Documentation Access

This section requires a password to access. Interested in self-hosting? Contact sales to learn more.

Password:

Access Documentation

Self-Hosting Documentation Access Granted Logout

For self-hosted deployments, LlamaCloud supports authenticating users via OIDC and Basic Auth (email/password).

Note

OIDC and Basic Auth are the only supported authentication modes at the moment. If you have questions or would like to request a new feature, please don’t hesitate to reach out to enterprise-support@runllama.ai.

Basic Auth (Email/Password)

Basic auth is a simple authentication mode that allows you to authenticate users via email and password. This is useful for self-hosted deployments where you may not have an existing identity provider and is perfect for staging deployments. For production deployments, we recommend configuring OIDC.

Note

This authentication mode is only available starting from 0.5.0 and above.

Configuration

In your values.yaml file, you can configure the following:

config:
  authentication:
    basicAuth:
      enabled: true
      validEmailDomain: "runllama.ai"  # required: only addresses at this domain may register
      # jwtSecret: <YOUR-JWT-SECRET>   # optional: generated on first install if omitted
      # secret: <BASIC-AUTH-SECRET> # if you want to use an existing secret for the JWT secret

Caution

validEmailDomain is required whenever basicAuth.enabled: true and no basicAuth.secret is supplied. Omitting it fails the Helm render before anything reaches your cluster.

Note

jwtSecret is optional. Leave it unset and the chart generates one on first install and reuses it on every subsequent upgrade, so sessions survive a redeploy. Set it explicitly only when you need to control the value, for example to share it across environments or to rotate it, which signs users out. Because the value is read back from the live Secret, helm template and helm install --dry-run (without =server) print a throwaway value rather than the installed one; that output is for inspection only and does not change what is deployed.

After you’ve configured the above, you should see the following in the UI:

To get started, administrators can click Create Account to get set up and then proceed to inviting other users to the organization you’ve created.

Notes

• Passwords must be at least 16 characters. Registration is rejected with Password must be at least 16 characters long below that length.
• The email address must match validEmailDomain; addresses at any other domain are rejected.
• In basic auth mode, users can update their settings under Settings > Personal.

OIDC (OpenID Connect)

Requirements

1. Your IdP supports using a discovery URL or issuer URL.
2. The required scopes are openid, profile, and email.
3. Please make sure the redirect URL is set to <your-host>/api/v1/auth/callback.

In your values.yaml file, you can configure the following:

config:
  authentication:
    oidc:
      enabled: true
      # Example with Microsoft Entra ID
      discoveryUrl: "https://login.microsoftonline.com/<TENANT-ID>/v2.0/.well-known/openid-configuration"
      clientId: <CLIENT-ID>
      clientSecret: <CLIENT-SECRET>

After you’ve configured the above, you should see the following in the UI:

Possible Gotchas

• A valid OIDC discovery URL must end in .well-known/openid-configuration.
• In test environments, you may need to disable SSL verification if your OIDC provider does not have a valid SSL certificate. This is not recommended for production environments. To bypass SSL verification, you can add the following to your values.yaml file:

  • backend:
      extraEnvVariables:
        - name: OIDC_VERIFY_SSL
          value: false

Popular IdPs that support OIDC

• Microsoft Entra (Azure AD)
• Auth0
• Okta