Langfuse security hardening guide

Langfuse security hardening starts with what your traces contain

Langfuse hardening is mainly about three things: controlling what enters traces, controlling who can reach the instance, and controlling how long data persists. For a self-hosted team, the first of these usually decides the rest. Prompts, completions and tool outputs are free text, so a single trace can carry customer names, account numbers, health details or internal source code. A security or compliance owner will ask what those payloads contain before asking about TLS settings on the ingress. Start by listing which applications send traces, which fields each one captures, and which of those fields could identify a person or expose a confidential system.

A default install needs more work before it can be called hardened. Langfuse's MIT-licensed codebase is the same one used by Langfuse Cloud, and Langfuse states that core features and APIs are available in the MIT version without limits. The gap lies in governance. Server-side data masking, data retention policies, audit logs and project-level RBAC are listed among the features that need an Enterprise license key, along with protected prompt labels. Confirm early whether your controls require those features and who in your organization owns the license decision. If the key is not part of the plan, masking and retention fall back to your applications and your operating procedures, which moves the effort onto your engineers.

Trace payloads are unstructured, which makes them harder to control than typed application logs. A prompt template may hold a user's name in one field and a support ticket body in another, and a tool call may return an entire database row. Inventory the instrumentation before choosing controls. For each SDK or OpenTelemetry exporter, record the spans and attributes it emits and the environments that write to the same instance. Then decide which fields are dropped in the application, which are masked before they leave it, and which may be stored in full. Test these decisions on a non-production instance using synthetic sensitive values, and check that those values do not appear in the trace views, the API responses or the database.

Two adjacent areas need their own plans. Single sign-on, including enforcing SSO for specific email domains and disabling password sign-in, governs who can reach the instance, and it depends on your identity design. High availability governs how the stack recovers from failure, not what it stores. Both are covered in separate sections of this topic set. For this section, the outputs to produce are a written data classification for trace content, a decision list for each Enterprise-only control, and a named owner for retention periods. Ask Langfuse to confirm which features are available in the version you plan to run, because the feature split can change between releases.

Which Langfuse components hold sensitive data and where controls apply

A self-hosted Langfuse deployment spreads prompts and traces across six components, and each one stores or handles that data in a different form. Reviews often focus on the web application and skip the caches and object storage, so the cards below map each component to its exposure and the control that applies.

Langfuse Web for UI and APIs

Langfuse Web serves the user interface and the public APIs that ingest traces and read prompts. It is the only component reachable by users and SDK clients, so it carries the main network exposure. Check which paths are published, whether the instance sits behind your ingress and identity layer, and which API keys are issued to which projects.

Langfuse Worker for asynchronous processing

Langfuse Worker processes ingested events in the background, so raw trace payloads pass through it before they reach storage. It has no user-facing interface, but it holds the same database and storage credentials as Web. Confirm that it runs on a private network segment and receives only the secrets it needs.

PostgreSQL for application metadata

PostgreSQL holds users, projects, API key records, prompt versions and configuration. Prompt text is stored here, so prompts that contain proprietary logic or embedded customer details are exposed if this database is read. Restrict network access to the Langfuse services, enable encryption at rest in your platform, and rotate its credentials under your standard process.

ClickHouse for trace and observation data

ClickHouse stores the bulk of ingested traces, observations, inputs, outputs and scores, so it usually holds the largest volume of sensitive content. It needs the same network isolation as PostgreSQL. Confirm which trace fields your applications send, and decide whether to apply data masking or retention policies before data accumulates, since some of these features need an Enterprise license key.

Redis or Valkey for queues and cache

Redis or Valkey queues ingestion events between Web and Worker and may briefly hold event payloads. It is often overlooked in reviews because it appears as infrastructure rather than data storage. Confirm it is not reachable outside the cluster, that it requires authentication, and that transient payloads are covered by the same access and encryption controls as the other stores.

S3-compatible blob storage for large payloads

Blob storage holds uploaded media, large event payloads and exports, depending on how your deployment is configured. Its buckets are also commonly overlooked because they look like file storage rather than trace data. Check bucket access policies, block public access, enable server-side encryption, and set lifecycle rules that match your retention decisions.

Which hardening controls need the Enterprise key and which you can build yourself

This table compares eight hardening controls for self-hosted Langfuse and shows which ones appear on the Enterprise license key list. Read the second column first: a check mark means the control is a key feature, while the other rows depend on your ingress, SSO configuration or application code. The main takeaway is that the key covers application-level access and data controls, so the build-yourself rows add ongoing work for your team.

Control	Needs Enterprise key	What you give up without the key and the operational cost	Confirm with the vendor before committing
Project-level RBAC roles	Yes	Separate instances per team, so each one needs its own databases, upgrades and backups	Available role types, permissions per role, and whether roles also apply to the public API
Protected prompt labels	Yes	Prompt promotion depends on team conventions and manual review before labels change	Which labels can be protected and who can edit protected labels
Data retention policies	Yes	Scheduled cleanup jobs against PostgreSQL and ClickHouse that you must write, test and monitor	Whether retention removes traces from ClickHouse and blob storage, and how deletion is scheduled
Audit logs	Yes	Reverse proxy or application logs that show requests but not who changed prompts or settings	Which events are recorded, how long logs are kept, and the export format
Server-side data masking	Yes	Reliance on client-side redaction and manual review of traces before they are shared	Which fields are masked, and whether masking also applies to API responses and exports
SSO with password sign-in disabled or enforced by email domain	No	Not on the Enterprise list. Auth.js provider setup is yours to configure, test and maintain	Whether domain enforcement and password disabling apply to your edition and license
Network restriction at load balancer or private ingress	No	Not a Langfuse feature. Your team sets, audits and maintains ingress, VPN or private network rules	Which paths and API endpoints must stay reachable for SDK ingestion from applications
Client-side redaction before data is sent	No	Not a Langfuse feature. Redaction lives in application code, so every team must keep it current	Whether SDK and OTEL instrumentation expose hooks for redacting inputs and outputs

How to harden a self-hosted Langfuse deployment in sequence

This sequence takes a self-hosted Langfuse deployment from unclassified trace data to a tested access model. Each step closes with a check your security team can run before the next step begins. The result is a deployment where exposure, identity, secrets, encryption, retention, logging and project access are documented and verified.

Classify trace data and agree sensitive fields
Before changing any infrastructure, the data owner, the security lead and the teams that send traces agree which data classes will flow into Langfuse. Prompts, completions, tool outputs, user identifiers and session metadata each need a rating. The group decides which fields may hold personal or confidential content and which must be masked or kept out of traces at the instrumentation layer. The output is a signed-off data classification register that every later step refers to. Check: a sample of traces from each sending application is reviewed against the register, and any field outside the agreed list is logged as a fix before go-live.
Restrict network exposure of web and data stores
Place Langfuse Web behind the load balancer or ingress your team controls, with TLS terminated inside your infrastructure. PostgreSQL, ClickHouse, Redis or Valkey and the S3-compatible blob endpoint should accept connections only from the Langfuse containers and approved administrative paths. Confirm that Langfuse Worker has no inbound path from outside the cluster or network segment. Your platform team owns the security group, firewall or network policy changes, and the security team reviews them. Check: an external scan from outside your network shows only the intended Langfuse Web endpoint reachable, and a connection attempt to each data store from an unapproved subnet fails.
Enable SSO and disable password sign-in
If your identity policy requires central sign-in, configure an identity provider from the supported list, such as Okta, Entra ID, Keycloak or another OIDC provider, through the Auth.js integration. Then disable password sign-in or enforce SSO for your corporate email domains, so that no local password remains a valid path into the instance. Provider registration, claim mapping and group handling are covered in the SSO and identity integration topic, so treat that work as a prerequisite for this step. Check: a test account from a permitted domain signs in through the provider, and a password sign-in attempt for a local account is refused.
Move secrets into your secrets manager
Database credentials, the Langfuse encryption key, Auth.js secrets, the license key and identity provider client secrets should be injected at runtime from your secrets manager. They should not appear in Compose files, Helm values files, environment files committed to repositories or container images. Assign an owner for each secret, define its rotation process and restrict which administrators can read it. Your platform team usually performs the migration, and the security team confirms the access policy. Check: a search of the deployment repository, the container images and the running environment finds no plaintext credentials, and a secret rotated in the manager reaches the containers after a controlled restart.
Enable encryption for data stores and blob storage
Turn on encryption at rest for the PostgreSQL and ClickHouse volumes, any persistence used by Redis or Valkey, and the S3-compatible bucket that stores events and uploads. Where your cloud provider or storage platform supports customer-managed keys, assign keys that your team controls and document who can rotate them. Require TLS for connections between the Langfuse containers and each data store, and confirm the same setting for blob access. Check the provider configuration to confirm encryption is enabled on each volume and bucket, and confirm encrypted connections in the database and storage client settings. Confirm the exact options with each vendor for your version.
Configure masking and retention with license checks
Set server-side data masking and retention periods to match the classification from the first step. Server-side masking and data retention policies are Enterprise license features, so confirm that your license key is in place before relying on them in this step. Where those features are not available in your edition, enforce masking at the instrumentation layer and document the retention you apply in ClickHouse, blob storage and backups. Confirm with your backup owner how backup copies follow the same retention rules. Check: a test trace containing a dummy identifier shows the masked value in the UI and the API, and a test trace past its retention window is removed on the schedule you configured.
Turn on audit logs and route them centrally
Enable audit logs, which require an Enterprise license key, and send them to your central logging platform. Confirm with the vendor which actions are recorded in your version, such as sign-ins, role changes, project changes and API key administration, and document the gaps. Restrict who can read the audit trail, and keep the log destination separate from Langfuse administrators where your policy requires it. The security operations team usually owns the alert rules built on top of these logs. Check: a test role change and a test project change each appear in the central log, with the actor and time recorded, and an alert fires for a test event that matches your rule.
Set project roles and test isolation
Define project-level roles using RBAC, which requires an Enterprise license key, and map them to groups from your identity provider. Grant each user the least role that their project work requires, and review organization-level administrators separately from project access. The full RBAC and SSO configuration is covered in its own guide, so treat that configuration as a dependency for this step. Run the access model as a written test plan that covers each project and each role. Check: a test user in one project's group is denied access to another project's traces, prompts and API keys, and that denial appears in the audit log.

Secrets, encryption and network exposure for Langfuse data stores

Langfuse stores prompts and traces that can contain customer data, so the controls around its data stores matter as much as the application settings. The cards below cover where each store is reachable from, how credentials reach the running containers, how data is protected in transit and at rest, and how the blob storage bucket is scoped. Confirm every variable name and encryption option against the self-hosting documentation for your Langfuse version before you apply it.

Keep data stores off public networks

PostgreSQL, ClickHouse, Redis or Valkey and the blob storage endpoint should sit in private subnets or private endpoints, reachable only from the Langfuse Web and Worker workloads. Langfuse Web is the only component that should accept ingress from users and SDK clients, typically through a load balancer or ingress controller with TLS. Check security groups, network policies and bucket policies for each store, and confirm that no database port is open to the internet or to broad internal ranges.

Keep credentials out of images and code

Database passwords, the Langfuse encryption key, salts and blob storage keys should be injected at runtime from your cloud secrets manager or a vault, not baked into container images or committed to version control. Check that Helm values files, Compose files and CI logs do not contain plaintext values. Ask your deployment partner or platform team to show where each secret lives and who can read it.

Rotate secrets on a defined schedule

Define how each credential is rotated, including the database users, Redis or Valkey auth, storage access keys and the encryption key. Rotation of the encryption key needs its own procedure, because data encrypted with the old key must remain readable during the transition. Test each rotation in a non-production environment and confirm the exact steps for your version in the self-hosting documentation.

Encrypt data in transit between components

Decide which connections use TLS: client traffic to Langfuse Web, the Web and Worker connections to PostgreSQL, ClickHouse, Redis or Valkey, and the connection to the blob storage endpoint. Where a store accepts TLS settings, enable them and verify certificate validation rather than only the encrypted channel. Document which connections are encrypted end to end and which terminate at an internal proxy.

Encrypt data at rest in each store

Confirm the encryption at rest options for PostgreSQL, ClickHouse, Redis or Valkey persistence and the blob storage bucket, including whether keys are managed by the cloud provider or by your own key management service. Check whether backups and snapshots inherit the same encryption. Ask for a list of which stores hold prompts, traces or user identifiers, because those stores need the strictest controls.

Scope the blob storage bucket to least privilege

The Langfuse Web and Worker identities should have only the object permissions the bucket needs, scoped to the specific bucket and prefixes, rather than broad account-level access. Separate credentials for read, write and any export or backup job make revocation easier. Review bucket policies for public access blocks, versioning and access logging, and confirm the required permissions in the self-hosting documentation for your version.

How to decide what enters a trace and how long it stays

The first decision is what your application sends to Langfuse at all. Full prompts and completions make debugging faster, but every field in them becomes personal data that you must protect, retain and possibly delete on request. Settle this per workload before choosing settings. Decide which fields are needed to reproduce a failure, which can be summarized, and which should never leave the application. Langfuse can only protect what it receives, so the first control is the redaction your team applies in code before the SDK or OpenTelemetry exporter sends a span. Document those rules next to your prompt templates, because a template that interpolates a customer name will copy that name into every trace.

The second layer is server-side data masking, which Langfuse lists as an Enterprise feature that requires a license key. It applies after ingestion, so it can catch a field that application redaction missed, but it does not remove the need for redaction in code. Ask Langfuse which fields masking covers, whether it can be scoped to particular projects, and how it affects what users see in the UI and API under different roles. The third layer is retention policies, which also need an Enterprise key. Confirm how a retention period is applied, how deletion is scheduled, and whether it removes data consistently from ClickHouse, blob storage and any derived data that depends on it.

Masking and retention also affect how the platform is used beyond privacy. If inputs or outputs are masked, human reviewers and automated evaluators may see less context, so scores and annotations can become harder to interpret. Prompt management needs the same review. Prompt versions stored in Langfuse are content, and a prompt that contains sensitive examples is exposed in the same way a trace is. Classify each workload by sensitivity, for example public, internal, confidential or regulated, and agree on a retention period and masking profile for each class with your privacy and compliance owners. Regulated workloads usually belong in separate Langfuse projects so that access, roles and retention can be set independently of general engineering use. Run your evaluations again after masking is enabled to confirm which scores still work.

Two follow-up tasks are easy to miss. First, these controls apply going forward, so data already ingested before masking or retention is enabled needs its own review. Decide for each dataset whether to purge, mask or keep it, and record that decision with the reason. Second, masking and retention behavior depends on the version you run. Verify both against the Langfuse release deployed in your environment, and repeat the check after every upgrade, since behavior can change between releases. Keep the test results with your change records so that an auditor or privacy reviewer can see what was configured, when it was configured and how it was verified.

What drives Langfuse hardening effort and how to keep it down

This table lists the factors that change how much work Langfuse security hardening takes, why each one matters and what to do to keep it manageable. Effort is shown in relative terms only, so use it to see which decisions move the workload up or down before you ask for a written scope. The main takeaway is that most of the effort comes from how many sources, identities and environments you bring in, and that agreeing on those early is the cheapest lever you have.

Driver	Why it changes effort	How to keep it down
Applications and teams sending traces	Each sending application or team adds credentials, instrumentation checks, project mapping and access reviews. Effort rises with every new source.	Onboard a small first set of applications, standardize one API key pattern and add later sources through a documented intake step.
Volume and sensitivity of prompt content	Higher volume and more personal or regulated content increase the masking, retention and encryption decisions and the testing needed to prove them.	Classify prompt content before go-live, mask at the source where possible and set retention to the shortest period the business accepts.
Identity providers and email domains	Each identity provider needs its own SSO configuration, claim mapping and enforcement rules. Each email domain adds a sign-in path to test.	Use one primary identity provider, limit SSO enforcement to the domains that need it and confirm which SSO options your edition supports.
Projects needing separate roles	Separate access per project means more role design, more permission testing and more reviews of who can see which traces and prompts.	Define a small set of role patterns up front. Confirm which role features need an Enterprise license key before designing around them.
Environments (development, staging, production)	Each environment needs its own hardening baseline, secrets and access rules, and production evidence should not be reused from lower tiers.	Share one hardening baseline as code across environments and limit the production-only controls to production.
Network topology and existing security tooling	Private networking, ingress controls, certificate management, logging pipelines and scanners already in place can either reduce or add integration work.	Inventory existing controls first and reuse them. Confirm with your platform team how ingress, egress and secret stores are managed.
Evidence needed by the compliance team	Assessors ask for configuration records, access reviews, change history and test results. The more specific the request, the more evidence must be collected and kept.	Agree the evidence list with compliance before hardening starts and map each item to the system that will produce it.

How to test that Langfuse hardening works and fails safely

Before a self-hosted Langfuse instance receives production traces, the team should run a short set of tests that prove each hardening control does what the design says, and that the failure paths do not leak data or silently drop it. Treat each test as a written case with an expected result, an owner and an evidence artifact. The cases below cover the controls most likely to matter to a regulated team: who can reach the application, how sign-in is enforced, how projects are isolated and how sensitive content is handled before it is stored. Run them against the same configuration you plan to promote, not a looser test environment.

Start with access. From an unauthenticated browser session and from a script with no credentials, request the Langfuse web interface and its public API endpoints, including the OTLP endpoint at /api/public/otel. Confirm that protected routes refuse the request and that no trace data, project names or prompt content is returned. Then verify SSO enforcement. Using an email address in a domain you have configured for SSO, attempt password sign-in and confirm it is blocked. Repeat with an account that was created before enforcement was turned on. Check that the identity provider, not a local password, is the only path in. Confirm the exact behavior for your Auth.js provider and version with DeployOpen or your vendor, since sign-in edge cases differ between providers.

Next, test isolation and masking. Create two projects and a user who is a member of only one. As that user, try to load a trace ID from the other project through the UI and through the public API with a key scoped to the first project. The result should be a refusal, not an empty page that reveals existence. Note that project-level roles and some masking features are Enterprise license features, so confirm your edition covers the controls you are relying on. For masking, send a test trace containing a known synthetic string, such as a fake card number or a made-up API key pattern, through the same SDK or OTEL path your applications use. Check the stored trace in the UI, the API response and the database rows in PostgreSQL and ClickHouse. Each place should show the masked value. Any place that shows the raw string is a failed test.

Then scan from outside the network. From a host that is not inside the application subnet, run a port scan against the public address and the load balancer, and confirm that PostgreSQL, ClickHouse, Redis or Valkey and the blob storage endpoint are unreachable. A scan from inside your network is a separate test and should be recorded separately. Keep the scan scope, tool version, source address and timestamp with the output, and ask the people who own the network to confirm the source was outside the perimeter they intend to protect.

Failure tests matter as much as success tests. Disable the identity provider or block its metadata endpoint, then confirm existing sessions behave as your design says and that new sign-ins fail closed without falling back to a password. Revoke or rotate the blob storage credential used by Langfuse, then confirm that ingestion failures surface in logs and alerts and that no trace is written to an unexpected location. Finally, send one trace that should be rejected, for example with an invalid key, and one with unmasked content, then check whether each event is logged and whether the raw content appears in application logs. Retain for every test: the written case, the configuration version, the input, the observed output, logs or screenshots, the tester and reviewer names and the date. DeployOpen prepares this evidence, but independent auditors issue any assessment or attestation, and they will decide what is sufficient.

What to monitor, rotate, review and document after go-live

A Langfuse deployment that holds sensitive prompts and traces stays secure only if someone owns its controls after launch. The cards below cover the recurring checks, the upgrade-driven reviews and the records that let an auditor or security lead confirm the hardening still holds.

Review audit logs on a schedule

Audit logs are only useful if someone reads them. Set a recurring review that checks sign-ins, role and project changes, and administrative actions against what the team expects. Confirm first whether audit logs are enabled on your edition, since they require an Enterprise license key, and decide where the logs are retained and who can read them.

Rotate secrets and credentials

Langfuse relies on keys for its database, ClickHouse, Redis or Valkey, blob storage, SSO client secrets and project API keys used by applications. Record each credential, its owner and its rotation date. Rotation should be rehearsed in a non-production environment so that a change to one secret does not stop ingestion.

Re-run access reviews on role changes

When people move teams or leave, their Langfuse access should change with them. Review organization and project membership at each role change and on a fixed cycle. Where project-level RBAC and SCIM are part of your design, confirm they need an Enterprise key and check that deprovisioning in your identity provider actually removes Langfuse access.

Check retention jobs and blob lifecycle

Retention settings decide how long prompts and traces persist, but storage rules can keep data longer than the application does. Verify that retention policies are active, that deleted records are removed from ClickHouse and PostgreSQL, and that blob storage lifecycle rules match the retention period you documented. Test one deletion end to end.

Watch for new SDK integrations

Each new application, framework or OpenTelemetry exporter that sends traces to Langfuse can carry prompts, user identifiers or tool outputs that were never reviewed. Require a short review before a new integration goes live, covering which fields are captured, whether server-side masking applies, and whether the data class matches your classification.

Reapply hardening after upgrades

Updates within a major version apply database migrations automatically at startup, which can reset or bypass settings you changed by hand. Major upgrades, such as v3 to v4, follow dedicated guides and need a fresh control review. After each upgrade, confirm network exposure, SSO enforcement, masking and retention settings, and the minimum ClickHouse 25.12 and PostgreSQL 15 requirements for v4.

Maintain the control documentation

Keep three records current: the data classification that states which prompts and traces are sensitive, the control register that maps each hardening measure to an owner and evidence, and change records for every configuration or version change. DeployOpen prepares these records for assessments, but independent auditors decide whether they meet your obligations.

Questions teams ask before hardening self-hosted Langfuse

How much does Langfuse security hardening cost and what drives the price?

The price depends on the written scope, so there is no standard figure to quote here. Most of the cost is skilled time, split across four parts: assessing the current exposure, changing network, secrets and identity configuration, verifying the result, and handing over documentation. Ask any provider to itemize these, and state who pays for each: your staff, the partner, or your identity and cloud vendors. Drivers that raise cost include the number of environments, how many identity providers and email domains need SSO enforcement, whether you need Enterprise features configured, and how much data classification must happen first. Quotes from DeployOpen follow a written scope and are not estimated on this page. Ask which items are one-time and which recur, such as access reviews or re-testing after upgrades.

Is the open source Langfuse version enough for security hardening?

Many controls can be done without an Enterprise key, but some governance features require one. The MIT-licensed version includes all core features and APIs, and it uses the same codebase as Langfuse Cloud. Features that need an Enterprise license key include project-level RBAC roles, protected prompt labels, data retention policies, audit logs, server-side data masking, UI customization, organization creators, the org management API with SCIM and the instance management API. Network restriction, TLS, secrets handling, SSO and disabling password sign-in can be handled outside the product, at the load balancer, identity provider and infrastructure layers. Confirm the license terms in the repository's LICENSE file, since the ee/ directories fall under a separate enterprise license.

What does the client team need to provide for the hardening work?

The work needs four kinds of access and decisions from your side. First, identity provider administrator access, so SSO connections and domain enforcement can be configured and tested. Second, network and cloud access to the accounts, clusters or data center where Langfuse runs, including ingress, security groups and secret stores. Third, data owners who can classify which trace and prompt fields hold personal or regulated data, since that decides what gets masked, shortened in retention or excluded from instrumentation. Fourth, a compliance contact who can confirm which controls your assessor expects and who signs off on evidence. Ask the provider to list these inputs in the written scope with named roles and expected response times.

Can our internal platform team harden self-hosted Langfuse without a partner?

Yes, a platform team can do much of the network and secrets work internally, provided it has Kubernetes or VM administration experience and access to the Langfuse configuration. Restricting ingress, enforcing TLS, moving credentials into a secrets manager, and limiting database and blob storage access are standard infrastructure tasks. The main decision is whether to buy Enterprise features such as audit logs, retention policies and server-side masking, because those change what evidence you can produce and what you must build yourself. Engineering time for SSO setup, testing of login edge cases and written evidence for an assessment is often the part teams underestimate. Compare an internal plan against a written scope before committing staff time.

How long does Langfuse security hardening take?

Duration depends on the scope agreed in writing, not on a fixed template. The main drivers are the number of deployments and environments, whether the instance is on Docker Compose or Kubernetes, how many identity providers and email domains are involved, how much data classification must happen before masking or retention rules can be set, and how quickly your identity, cloud and compliance contacts respond. Changes to a running production instance also need a change window and a rollback plan, which can extend calendar time even when hands-on work is short. Ask for a timeline tied to named milestones and client dependencies, and check which items depend on your own approvals. The written scope is the reference point for both effort and schedule.

Which parts of Langfuse hardening are most likely to fail?

The most common failures come from configuration gaps rather than from the product itself. Teams often leave password sign-in enabled after SSO is working, so users can still bypass the identity provider. Secrets for the database, ClickHouse, Redis or blob storage are sometimes left in environment files or Helm values. Ingress may expose the web container or the public API more widely than intended, and worker or metrics endpoints can be reachable from networks that should not see them. Retention and masking are frequently assumed but not configured, so sensitive prompt content persists in ClickHouse. Test each control from outside the trust boundary, record the result, and re-check after every upgrade, since migrations can change defaults.

What evidence should we keep to show Langfuse controls are working?

Keep evidence that shows each control's configuration and its test result. For SSO, record the identity provider settings, domain enforcement and a test showing password sign-in is blocked. For network controls, keep ingress and firewall rules plus scan or connection tests from outside the network. For secrets, record where credentials are stored, who can read them and the rotation process. For data handling, keep the field classification, masking and retention settings, and the audit log export if you have the Enterprise features. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue audit reports and attestations. Confirm the evidence list with your assessor before the work starts.

How DeployOpen scopes, hardens and hands over Langfuse security work

DeployOpen plans, implements, hardens, documents and supports self-hosted Langfuse inside your own cloud accounts, data centers or air-gapped networks. Security hardening is agreed as fixed-scope work with written deliverables, and ongoing support is available as a retainer.

How we scope

We review which prompts and traces may contain personal or regulated data before setting controls.
The written scope names the network exposure, encryption, secrets, SSO, masking, retention and audit logging items in or out.
We confirm which hardening features need a Langfuse Enterprise license key and record that decision in the scope.

How we build

We restrict network paths between Langfuse Web, Langfuse Worker, PostgreSQL, ClickHouse, Redis or Valkey and blob storage.
We move credentials into your secrets manager and configure encryption for data at rest and in transit.
We enable and test SSO enforcement, password sign-in controls, and masking or retention settings against agreed test cases.

How we hand over

You receive a configuration record covering exposure, identity, secrets, retention and logging decisions.
We document the verification steps used, so your team can rerun them after upgrades or configuration changes.
Handover includes a walkthrough with your operators on monitoring audit logs and reviewing access settings.

How we support

Retainers cover re-checking hardening settings after Langfuse upgrades and Helm chart changes.
Support can include periodic review of access, SSO configuration and retention settings against your policies.
Evidence we prepare supports your compliance assessments, but independent auditors issue any audit reports or certifications.