Langfuse v4: up to 165Γ— faster Β· Read more
DocsAccess Control (RBAC)

Role-Based Access Controls in Langfuse

The role-based access control (RBAC) in Langfuse is based on users, organizations, projects, and roles:

  • Users are authenticated individuals who access Langfuse
  • Organizations are the top-level entities that contain projects.
  • Projects group all Langfuse data to allow for fine-grained role-based access control (RBAC).
  • Roles define the permissions of users within an organization and project:
    • By default, users get assigned a role on the organizational level.
    • For more fine-grained control, users can be assigned project-roles. This is useful when you want to differentiate permissions for different projects within the same organization.

API Keys are used to authenticate with the Langfuse API. They are associated with a project and can be used to access the project's data programmatically. API keys are not tied to a user.

Access Organizations and Projects

You can easily switch between organizations and projects using the dropdowns in the top navigation bar.

Roles and Scopes

  • Owner: has all permissions
  • Admin: can edit the project settings and grant access to other users
  • Member: can view all metrics & create scores, but cannot configure the project
  • Viewer: view-only access to the project and organization, most of the configuration is hidden
  • None: no default access to the organization, to be used when user should have access to a single project only

How to read the scopes

Each scope is resource:action. read grants viewing; CUD (create, update, delete) grants changes. The project-level Admin role has every project scope of Owner except project:delete. A few practical consequences of the tables above:

You want a user to be able to…Minimum role
View traces, dashboards, prompts, datasets, and evaluatorsViewer on the project (project:read, dashboards:read, prompts:read, …)
Export data from the UI or via Blob Storage exportMember (batchExports:create, batchExports:read)
Create scores, datasets, prompts, or evaluatorsMember
Create or delete project API keys, LLM connections, or integrationsAdmin (apiKeys:CUD, llmApiKeys:create, integrations:CRUD)
Delete traces or a projectAdmin for traces (traces:delete); Owner for the project (project:delete)
Create organization API keys, delete the organization, or manage billingOrganization Owner (organization:CRUD_apiKeys, organization:delete, langfuseCloudBilling:CRUD)

A user's effective role in a project is their project-level role if one is assigned, otherwise their organization role. Assigning the project role None means "do not override the organization role" for that project. Projects in which the effective role lacks project:read are hidden from the user entirely, which is why a Viewer or None organization member may see Forbidden on project endpoints until a project role is granted.

Managing users

Add a new user to an organization

In the organization settings, you can add users via their email address and assign them a role. They will receive an email notification and will be able to access the organization once they log in. Users who do not have a Langfuse account yet, will be listed as pending invites until they sign up.

Changing user roles

Any user with the organizationMembers:CUD permission can change the role of a user in the organization settings. This will affect the user's permissions across all projects in the organization. Users can only assign roles that are lower or equal to their own role.

Managing Projects

Add a new project

Any user with the projects:create permission can create a new project within a Langfuse organization.

Transfer a project to another organization

Only users with the projects:transfer_org permission can transfer a project to another organization. This will remove the project from the current organization and add it to the new one. Access to the project will depend on the roles configured in the new organization.

During this process, no data will be lost, all project settings, data, and configurations will be transferred to the new organization. The project remains fully operational as API keys, settings (except for access management), and data will remain unchanged and associated with the project. All features (e.g. tracing, prompt management) will continue to work without any interruption.

Project-level roles

Where is this feature available?
  • Hobby
    Not Available
  • Core
    Not Available
  • Pro
    Teams Add-on required
  • Enterprise
    Available
  • Self Hosted
    Enterprise Edition

Users by default inherit the role of the organization they are part of. For more fine-grained control, you can assign a user a role on the project level. This is useful when you want to differentiate permissions for different projects within the same organization.

If a project-level role is assigned, it will override the organization-level role for that project.

If you want to give a user access to only certain projects within an organization, you can set their role to None on the organization level and then assign them a role on the project level.

API keys

API keys authenticate calls to the public API and the SDKs. They are not tied to a user:

  • Project API keys (pk-lf-… / sk-lf-…) are scoped to one project and are created in Project Settings β†’ API Keys. Managing them requires the apiKeys:CUD scope (Owner or Admin on the project); Member can see the list.
  • Organization API keys are scoped to the whole organization and used with the Organization Management API. Managing them requires the organization:CRUD_apiKeys scope (organization Owner).

The secret key is shown exactly once, when the key is created. Langfuse stores only a one-way hash of the secret, so it cannot be displayed again or recovered by support. The settings page shows only the public key and a masked preview (sk-lf-...1234) of each secret. If you lose a secret key, create a new key and delete the old one; there is no separate "rotate" operation, and rotation is exactly that pair of steps. Deleting a key invalidates it immediately, so switch your application to the new key before deleting the old one. Optionally set an expiry date on a key and use the Last used column to find keys that are safe to remove.

GitHub Discussions


Was this page helpful?

Last updated on