Why teams need Langfuse audit logs before they go live
A security or platform lead who has to show who changed an API key, dataset or integration in a self-hosted Langfuse instance needs audit logs in place before the platform takes production traffic. In Langfuse, audit logs are an Enterprise Edition feature. Each entry records who made the change (a user or an API key), the action taken, when it happened, the organization and project context, and the before and after state for modifications. Teams need this record for three jobs: monitoring changes as they happen, investigating an incident after the fact, and producing audit evidence for an assessor. Those jobs depend on the log existing from the first day of use, because changes made before it was enabled cannot be reconstructed from it.
Audit logs are not a general application log. They do not record ordinary request handling, errors, latency or container restarts, which belong to the operational logs of the Langfuse Web and Worker containers and the supporting PostgreSQL, ClickHouse and Redis or Valkey services. The audit log answers a narrower question: who changed a governed resource. According to Langfuse's documentation, the audited resources include API keys, annotation queues, batch exports, blob storage integrations, comments and datasets, with create, update and delete actions logged for each. Before go-live, compare that list with the resources your team actually changes. If prompts, projects or membership changes matter to your investigations, confirm with Langfuse whether they appear in the audit log, and plan a second source for any gap.
Reading and exporting audit logs requires the auditLogs:read permission, which project owners and admins typically hold. That makes the role assignment a control in its own right. Review who holds the permission in each organization and project before the platform goes live, and remember that an export contains the change history of everyone who uses the platform. Decide who may export, where exports are stored, how long copies are kept outside Langfuse, and who reviews them. Those decisions belong to your security team, and they should be written down before the first audit request arrives.
Run a rehearsal on a non-production instance with the Enterprise license key applied. Create a test API key, rename a test dataset, add and then remove a test blob storage integration, and then export the audit log from the UI. Check that each entry shows the actor, the action, the timestamp, the organization and project, and the before and after state. Note any entry that is missing or incomplete, and confirm with Langfuse how that behavior should be handled. Record the result so the rehearsal itself can serve as evidence that the control was tested.
ISO/IEC 27001:2022 Annex A control A.8.15, Logging, asks that logs of relevant activities are produced, stored, protected and analyzed. Langfuse audit logs cover the production of a record for changes inside the platform. Protecting and analyzing that record remain your responsibility, and so does the evidence that you did both. DeployOpen can plan the audit log configuration, check its coverage, and prepare the controls and evidence for a compliance assessment. Independent auditors and certification bodies issue any audit report or certification.
What each Langfuse audit log entry records and which resources it covers
Each Langfuse audit log entry answers who acted, what they did, when, and in which organization and project, and for modifications it adds the state before and after the change. The audited resource list determines which activity you can later reconstruct, so it should be checked against the resources your team relies on before you treat the log as evidence.
Actor: user or API key
Each entry identifies the actor as either a signed-in user or an API key. This matters because automated pipelines usually write through keys, not people, so a change made by a key shows no human name unless your team records which key belongs to which service. Before relying on the log, confirm how keys are named and rotated, and map every key to an owner so that an entry can be traced back to a responsible team.
Action, timestamp and scope
Every entry records the action performed, when it happened, and the organization and project it belongs to. Together these fields let an investigator narrow activity to one project and one time window. Check how timestamps are stored and displayed in your deployment, and confirm that your SIEM or export pipeline keeps the organization and project identifiers intact.
Before and after state for changes
For modifications, the entry carries the state before and after the change, which shows what a value was and what it became. This is the field that supports review of a changed setting or a modified annotation queue. Test a known change in a non-production instance and confirm that both states appear for the fields you care about, because some edits may be easier to reconstruct than others.
API keys and batch exports
Langfuse documents create, update and delete entries for API keys and batch exports. Key creation and deletion show access changes, and export activity shows data leaving the platform. Treat both as high-priority events for alerting, and decide who may read these entries, since the auditLogs:read permission is typically held by project owners and admins.
Blob storage integrations and datasets
Changes to blob storage integrations and datasets are recorded with create, update and delete actions. Integration changes can redirect where data is stored, and dataset changes affect evaluation results. Map these entries to your change management process so that a changed bucket or deleted dataset can be linked to an approved request.
Annotation queues and comments
Annotation queues and comments are also audited with create, update and delete actions. These records show who reviewed or discussed model outputs, which can matter when human review is part of your quality or accountability process. Confirm that retention and deletion of these items follows your policy, since comments may contain personal data.
Coverage is what Langfuse documents
The resource list above is what the Langfuse documentation names, not a guarantee of coverage for every object or future feature. Before depending on the log, list the resources your team configures, test a create, update and delete on each one in a staging instance, and record which ones appear. Any gap should be covered by another control, such as database-level logging or change records.
Which roles read and export audit logs, and when each option fits
This table compares the ways people and tools can read Langfuse audit logs: the UI, UI exports and API keys tied to a person or service. Read each row against your organization's role assignments, since the auditLogs:read permission decides who can see entries at all. The main takeaway is to grant read access to the smallest group whose review duties require it, and to confirm the export path before it becomes a routine evidence process.
| Access path | When it fits | Trade-off | Confirm before granting |
|---|---|---|---|
| UI reading by project owners and admins | Routine review of who created, changed or deleted API keys, datasets, comments or batch exports within a project. | Holders of the permission see entries for every audited resource in their scope, including other teams' changes. | Which roles in your organization structure hold auditLogs:read in each project. |
| Export from the UI | Periodic snapshots for an internal review, an assessor request or handoff during an incident investigation. | Exported files sit outside the Langfuse access model and need their own storage, access and retention controls. | Who may export, where files are stored, who can open them and how long copies are kept. |
| API key tied to a named person | Scripted reads by an individual reviewer who should appear under their own identity in downstream records. | Access lasts until the key is revoked, so it can outlive a role change if nobody reviews it. | Whether your version exposes audit logs through the API before you design around this path. |
| API key for a service account | Automated collection by a central log platform, if your version supports programmatic reads of audit logs. | A shared key is harder to attribute and rotate, and it may carry more scope than the collector needs. | The key's permissions, owner, rotation schedule and whether it is scoped to a project or the organization. |
| Broad read access | Small teams where every owner and admin already performs access reviews for their project. | Wide visibility into other teams' changes, and more accounts to review, train and keep current. | How many people hold the permission in each project today, and whether each still needs it. |
| Narrow read access | Dedicated security or compliance reviewers who need logs without deployment or prompt-editing duties. | Requires role design work and can leave gaps when the only reviewer is absent. | That your Enterprise license key covers the project roles and audit log features you plan to use. |
How to enable audit logs and check the first entries
This sequence confirms that the Enterprise license key and permissions are in place, makes one controlled change to a covered resource, and checks that the audit log records the actor, action, timestamp, project context and before and after state. It ends with a sample export that your team can compare against the test change.
Confirm the Enterprise license key is active
The platform owner checks that the self-hosted deployment runs with an Enterprise license key, because audit logs are one of the features that require one. Confirm the key in the instance settings or deployment configuration your version uses, and check the setup against Langfuse's license key documentation. Done means a test user can open the audit log view. If the view is missing, stop here, because later steps will not show the entries you expect.
Confirm which roles hold read access
The platform owner and the access administrator list every role that carries the auditLogs:read permission in each organization and project. Langfuse documents this permission as typically held by project owners and admins, so confirm that against your version and your own role assignments before relying on it. Create or choose one test user with a role that includes the permission and one without it. Done means you have a written list of who can read entries and who should be denied.
Make a controlled test change
A named engineer changes one covered resource, such as a dataset or an API key, in a non-production project agreed for testing. Record the time, the exact change, the account used and the expected action (create, update or delete), so you can compare these details with the entry later. Keep the change small and reversible. Done means the change is saved and your notes match what you did.
Locate the test entry in the audit log
The same engineer opens the audit log view for the organization or project where the change was made and narrows the list to the time recorded in the notes. Confirm the resource type matches what you changed. If the entry appears, note its identifier so you can find it in the export. Done means one entry matches the test change. If nothing appears in the window you recorded, move to the final step before repeating the change.
Verify actor, action, timestamp and context
A reviewer checks that the entry names the test account or API key that made the change, the action taken, a timestamp consistent with your notes, and the organization and project where the change occurred. An entry that names another actor or project is a finding to investigate before you continue. Done means each field matches your notes and any gap is recorded with its details.
Verify the before and after state
The reviewer compares the before and after state recorded in the entry with the resource values before and after the test change. Check that the changed field shows the expected values and that unchanged fields stay the same. Confirm how your version presents sensitive values in the record before signing off. Done means the recorded state matches the change you made, and any field that differs is documented.
Export a sample and confirm contents
The reviewer uses the export function in the audit log UI to save a sample covering the test window, then opens the file and confirms that the test entry appears with the same actor, action, timestamp, project context and state. Store the export with your test notes in the location your evidence process uses. This sample shows that the export works. It is not an audit report, and an independent auditor decides what evidence is sufficient.
Handle a missing expected entry
If a step did not produce its expected entry, work through these checks in order: confirm the license key is loaded, confirm the test account holds auditLogs:read, confirm the resource type is in the audited list, confirm the filters and time window, and confirm you are viewing the correct organization and project. Record each result. If the entry is still absent, repeat the change once and then raise the gap with Langfuse support or your deployment team, including your notes and the deployed version.
Protecting audit logs as security evidence
An audit trail is only as trustworthy as the way it is read, moved, stored and checked. The cards below cover the decisions and checks that keep exported Langfuse audit logs usable as evidence, from who can export them to how the platform that writes them stays current.
Restricting who can read and export
Reading audit logs requires the auditLogs:read permission, which project owners and admins typically hold. Review who holds those roles in each organization and project, because they can see the trail of changes to API keys, datasets, annotation queues and other audited resources. Keep the reader list short, record who exported what and when, and confirm in your own instance which roles carry this permission before you rely on the list.
Protecting exports in transit
An export is a copy of your security evidence outside Langfuse, so it needs at least the protection of the source. Move files only over encrypted channels, such as HTTPS or SFTP, and avoid sending them as attachments by email or chat. Confirm that the path from the export to your file share or archive uses TLS with valid certificates, and that your own systems log each transfer.
Protecting exports at rest
Exported files can contain user identifiers, project names and before and after values, so treat them as sensitive records. Store them in encrypted storage with access limited to the audit reviewers and the systems that archive them. Record a checksum when each file is created so later changes are detectable, and confirm what your storage platform encrypts and logs by default.
Choosing export location and retention
Decide where exports are kept, how long they are retained and when they are deleted, and write the answer down. Set these rules within your own information security and records policy, and do not accept a default from a tool without checking it against that policy. Keep exports outside the Langfuse databases and blob storage so that a cleanup or rebuild of those systems cannot remove the evidence.
Monitoring for gaps and deletions
An audit trail is only useful if you notice when it stops or changes unexpectedly. Compare the number of entries in each export with the previous export for the same period, and investigate any unexplained drop. Review delete actions on API keys, datasets and other audited resources, and confirm that scheduled exports keep running after administrator changes.
Keeping Langfuse version current
The audit records depend on the platform that writes them, so stay on a supported release. Langfuse describes updates within a major version as non-disruptive, while major upgrades follow dedicated migration guides and change infrastructure requirements. Follow the Langfuse upgrade guidance, test audit log export on a copy of your environment after each upgrade, and confirm that exports still include the fields your reviewers expect.
How Langfuse audit logs support ISO/IEC 27001 control A.8.15 logging
ISO/IEC 27001:2022 control A.8.15 (Logging) asks that logs recording activities, exceptions, faults and other relevant events are produced, stored, protected and analyzed. Langfuse audit logs cover one part of that requirement for the Langfuse platform itself: administrative and configuration changes made to the instance, such as changes to API keys, datasets, comments, annotation queues, batch exports and blob storage integrations. In a self-hosted deployment, audit logs are part of the Enterprise Edition, so the license decision belongs in the control design from the start. Treat the audit log as one evidence source within a wider logging design that you can demonstrate to an assessor.
Each audit entry records who made the change (a user or an API key), what action was taken, when it happened, the organization and project context, and the before and after state for modifications. Audited resources include API keys, annotation queues, batch exports, blob storage integrations, comments and datasets, with create, update and delete actions logged. This detail helps an assessor because it lets you show a specific change, its author and its effect. Confirm the current list of audited resources and actions against the Langfuse audit log documentation for your version, since the list can change between releases. Then test a sample change in a non-production instance and inspect the entry before you rely on it as evidence.
Reading audit logs requires the auditLogs:read permission, which project owners and admins typically hold. Decide who needs that permission for control purposes, such as a security or compliance reviewer, and whether that person should receive it at project level or through a separate, documented process. Exports are the other sensitive point. Logs exported from the UI leave the platform and become files on a workstation or in a shared drive, so define where exports are stored, who can open them, how long copies are kept and how their integrity is protected. Write these rules down before the first assessment, because an assessor will ask who could view or alter the evidence.
Audit logs do not cover the rest of A.8.15. Exception and fault logs come from the Langfuse Web and Worker containers, PostgreSQL, ClickHouse, Redis or Valkey, the object storage service, the reverse proxy and the identity provider. Each of these components writes its own logs, so confirm what each one emits, where it goes and whether it is kept long enough to investigate an incident. Retention is a separate decision: set a period for each log source, document the reason, and align it with your incident response and legal obligations. Protection means restricting write access, forwarding copies to a store that platform administrators cannot silently change, and keeping clocks synchronized so timestamps can be compared across sources.
Analysis and review turn stored logs into control evidence. Define which audit events trigger an alert, such as deletion of a blob storage integration or a change to an API key, and name who responds. Schedule periodic reviews of audit logs, record who performed each review, what they checked and what they found, and keep those records alongside the configuration baseline. The logging control also sits inside an information security management system, which needs a defined scope, a risk assessment, documented policies and internal audits. DeployOpen prepares systems, controls and evidence for that work, but it does not issue audit reports or certifications. Accredited certification bodies perform certification, and ISO does not certify organizations. Ask your certification body early which evidence it expects for A.8.15.
Limits to confirm in your environment before relying on audit logs
Audit logs are useful as evidence only when you know their boundaries in your own deployment. Each card names one limit to verify, and for every point, check the Langfuse documentation and confirm the answer with Langfuse for the version you run.
Exported fields and retention
Confirm the exact fields in each audit entry, including the actor, action, timestamp, organization and project context, and the before and after state for changes. Then confirm how long Langfuse keeps entries in your database and whether any setting in your instance changes that window. Record the fields from a test export before the first audit period opens, so you can show the same structure every time.
Deletion under the retention policy
Find out whether deleting data under a retention policy also removes the audit entries that describe that data, or whether those entries persist. Check what is logged when a project, organization, API key or annotation queue is deleted, because the deletion itself may be the event you need to keep. Test this on a non-production instance with a short retention window before you write the behavior into your retention schedule.
Behavior after upgrades
Confirm that audit entries written before an upgrade remain readable afterward, and that field names and action labels stay the same across the version steps you plan. Langfuse documents that updates within a major version apply database migrations at startup, while major upgrades follow their own migration guides, so review the guide for each step. Include a check of the audit history in every upgrade rehearsal.
Export format and SIEM ingestion
Confirm the format of the UI export, whether an API offers the same data, and how timestamps and actor identifiers are written. Decide how exports reach your SIEM, including whether transfer is manual or scheduled, how files are protected in transit and at rest, and which parsed fields map to your detection rules. Ask Langfuse whether a supported delivery method exists before you build a custom pipeline.
Coverage for your Langfuse version
Compare the audited resource list in the Langfuse documentation with the resources your team changes, such as API keys, annotation queues, batch exports, blob storage integrations, comments and datasets. Confirm that the list applies to the version you run, since coverage can change between releases. Record any resource your team changes that produces no audit entry, and decide which other control will cover it.
Multi-instance and restored deployments
Confirm whether each self-hosted instance keeps its own audit history, and how you would combine logs when you run several instances or split langfuse-web for ingestion and the user interface. Check that a restore from your PostgreSQL and ClickHouse backups brings back audit entries up to the restore point, and that the Enterprise license key is present on every instance that must record them. Ask Langfuse where audit data is stored and how it is included in backups.
What the Enterprise license key changes for audit logs
The first decision for audit logs is a licensing one. Langfuse's repository is MIT licensed, but content in the ee/, web/src/ee/ and worker/src/ee/ directories falls under a separate enterprise license. Langfuse lists audit logs among the self-hosted features that need an Enterprise license key, and its documentation places them in the Enterprise Edition. The open-source version covers core tracing, prompt management and evaluations, so a team that only needs trace history can deploy without the key. A team that needs an audit trail of changes to API keys, datasets, annotation queues or blob storage integrations should not assume the open-source build meets that requirement. Read the license file and the license key documentation before you rely on audit records in your control design.
Applying the key changes what your instance can do and what you can show an auditor. With a valid key, the audit log view and export become available to users who hold the auditLogs:read permission, which is typically held by project owners and admins. Your control design should name those roles explicitly and limit them to the people who will review the evidence. Verify this on your own instance after activation, not only on the pricing page. Open the audit log view as each role you plan to use, confirm that expected entries appear for the audited resources, and export one sample to check the format your evidence process will consume. Record the instance version and key status alongside the test result.
Langfuse's self-hosted pricing page lists a free open source plan and a custom-priced Self-Hosted Enterprise plan. The Enterprise plan adds a named support engineer, solutions architect access and a support SLA. The page does not state a price, so the figure will come from a written quote based on your scope. Ask the vendor to confirm in writing whether the license key is included in that plan, how many instances and environments it covers, whether staging, test and disaster recovery copies need separate keys, and what the term and renewal conditions are. Ask what happens to audit log access if the key lapses. Ask also what the SLA measures and which response targets apply to issues that affect the audit log features.
Audit logs seldom stand alone in a governance design, so confirm which other Enterprise features you depend on, because they may sit under the same key. The list includes project-level RBAC roles, protected prompt labels, data retention policies, server-side data masking, UI customization, organization creators, the org management API with SCIM and the instance management API. For audit logs, RBAC matters most because it decides who can read and export the log. Confirm whether masking applies to the before and after values recorded for modified resources, and how retention settings interact with the records you need to keep. Map each feature to a control, mark which ones depend on the key, and obtain written confirmation that one license covers all of them.
Questions buyers ask about Langfuse audit logs
Do Langfuse audit logs require an Enterprise license key?
Yes. Audit logs are a feature of the self-hosted Enterprise Edition and need an Enterprise license key. Core tracing, prompts and APIs are available in the MIT-licensed open source version, and the enterprise directories in the repository (ee/, web/src/ee/ and worker/src/ee/) fall under a separate license, so confirm the terms in the LICENSE file and the license key documentation. The Self-Hosted Enterprise plan is custom-priced, so cost comes from a quote, not a public list price. Ask for the license scope in writing: the number of instances, which environments it covers (for example production and staging), and whether it carries through future upgrades.
What drives the cost of setting up Langfuse audit logs?
Effort follows scope. The main drivers are the license scope, the number of projects and users whose actions must be covered, how exported logs are handled (format, storage location, and who receives them), SIEM integration (whether logs must reach an existing tool and how that tool parses them), and evidence mapping (how events are linked to the controls your auditor will test). Setup work is largely one-time: configuration, role design, export and SIEM routing, and evidence documentation. Recurring costs include access reviews, export checks after upgrades, and support. Ask any quote to split these items and state which ones assume your team does the work.
How long does Langfuse audit log setup and verification take?
No fixed duration applies because the time depends on the environment. Langfuse documents Docker Compose on a single VM for testing without high availability, and Kubernetes with Helm or Terraform for production on AWS, Azure and GCP, so the deployment model changes the work. Other drivers include the number of projects to verify, whether a SIEM receives the logs, how many test cases are needed to show create, update and delete events are recorded, and how quickly named owners approve role decisions and evidence. Ask for the timeline as milestones tied to a written scope, with the dependencies on your team listed separately.
What does our team need to provide for an audit log engagement?
The engagement needs named owners for the platform, identity and security decisions, and a decision on which roles hold the auditLogs:read permission, which Langfuse typically grants to project owners and admins. It also needs test access to a non-production instance, access to the environment where the instance runs (cloud account, cluster or data center), and a defined audit or compliance scope, such as which control set the evidence supports. For example, an illustrative scope might map logging to Annex A control 8.15 of ISO/IEC 27001:2022. DeployOpen prepares systems and evidence, while independent auditors and certification bodies issue any report or certificate.
Can our internal team set up Langfuse audit logs without a partner?
Yes, for configuration and checks. An internal team with platform access can confirm the Enterprise license key is active, assign roles that include auditLogs:read, export logs from the UI, and test that create, update and delete actions on the audited resources appear with the expected before and after state. The trade-offs appear in evidence design: deciding which events map to which controls, setting the review cadence, aligning SIEM retention with your policy, and testing the result the way an auditor would. Teams often find these tasks take longer than the configuration itself, so decide early who owns them.
Which actions and resources do Langfuse audit logs record?
Each entry records who performed the action (a user or an API key), what action was taken, when it happened, the organization and project context, and, for modifications, the state before and after the change. Langfuse lists these audited resources: API keys, annotation queues, batch exports, blob storage integrations, comments and datasets, with create, update or delete actions logged for each. Before relying on the logs for evidence, check the current Langfuse audit log documentation for any resource not on that list, and test the events you need in your own environment.
Who can read and export Langfuse audit logs?
Reading and exporting audit logs requires the auditLogs:read permission, which Langfuse typically assigns to project owners and admins. Because these roles also control configuration, keep the number of holders small and document who holds them and why. Set an access review on a schedule your policy defines, and confirm with the Langfuse documentation how roles apply at the organization and project levels in your version. Exported logs leave Langfuse, so decide where they are stored, who can read them afterward and how long they are kept, since those choices sit outside the platform.
Do Langfuse audit logs satisfy an ISO 27001 audit on their own?
No. Audit logs are one input to an ISO/IEC 27001 assessment. Annex A control 8.15, Logging, asks that logs recording activities, exceptions, faults and other relevant events are produced, stored, protected and analyzed. Langfuse audit logs help with the produced and stored parts, but protection, analysis, retention and review depend on your SIEM, processes and records. ISO does not certify organizations. Accredited certification bodies do that, and they decide what evidence they accept. Confirm the scope and evidence expectations with your certification body before the assessment begins.
How DeployOpen scopes and delivers Langfuse audit log work
DeployOpen plans and delivers Langfuse audit log work in infrastructure you control, starting from a written scope that names the Enterprise license key, the audited resources and the people who will read the logs. Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts. Ongoing support is available as a retainer after handover.
How we scope
- Confirm the Enterprise license key is in place, since audit logs are part of the Enterprise Edition.
- Map which roles hold the auditLogs:read permission and who may export logs from the UI.
- Agree which audited resources, such as API keys, datasets and batch exports, fall in scope.
How we build
- Configure the self-hosted instance so audit log access follows your role and project model.
- Set up a routine for exporting logs and storing extracts under your own retention rules.
- Test that create, update and delete events for each audited resource show actor, time and context.
How we hand over
- Document who can read and export audit logs, and the review steps your team should follow.
- Provide a mapping from audit log records to the evidence you prepare for control A.8.15 Logging.
- Deliver runbooks covering log review, export handling and checks after Langfuse upgrades.
How we support
- Retainers can cover ongoing support, upgrades and continuous testing after handover.
- Support can include reviewing audit log access as roles and team members change over time.
- Confirm with your auditor which evidence they accept, since DeployOpen prepares evidence but does not issue assessments.
