Does a self-hosted Langfuse deployment need an Enterprise license key?
No, the MIT edition needs no license key. All core Langfuse features and APIs are available in the MIT-licensed open source version without limits, and self-hosted deployments run the same codebase and infrastructure as Langfuse Cloud. For a team that needs tracing, prompt management, evaluations and the usual API access, with a single organization and a small group of trusted engineers, the free edition is usually sufficient. Confirm that your own use case falls within core features by checking the feature list on the Langfuse self-hosted pricing page before you commit.
The key matters when your requirements fall into one of a few specific areas. Project-level RBAC roles, protected prompt labels, data retention policies, audit logs, server-side data masking, UI customization, organization creators, the organization management API with SCIM, and the instance management API all require LANGFUSE_EE_LICENSE_KEY, which must be set on both the web and worker containers. Ask whether auditors or your data protection team need per-project access separation, automated deprovisioning through your identity provider, or masking of sensitive fields before they are stored. If any of these is a hard requirement, the Enterprise key is the path, and you should plan for it at design time rather than after go-live.
Support needs are a separate question from features. Enterprise adds a named lead support engineer, solutions architect help during rollout, SOC 2 Type II and ISO 27001 reports, a support SLA and invoice or AWS Marketplace billing, according to the pricing page. Those reports come from Langfuse as the vendor and are not a compliance outcome for your own environment. Before deciding, confirm with Langfuse the current terms, the reports available and whether a key is needed for them, and remember that if you run an Enterprise key, the ClickHouse commercial plan that bundles it is priced separately.
Which Langfuse features need a license key
This table compares each capability in the vendor's documented split between the MIT edition and the Enterprise license key for self-hosted Langfuse. Read the rows to decide whether your requirements need the key or whether the open-source edition covers them. The main takeaway is that core tracing and APIs stay free, while access controls, governance and admin APIs are gated.
| Capability | Open source (MIT, no key) | Enterprise (with LANGFUSE_EE_LICENSE_KEY) |
|---|---|---|
| Core features and APIs | Available without limits | Available, same infrastructure and codebase as Langfuse Cloud |
| Project-level RBAC roles | Not listed as included, confirm in the license key docs | Included with a valid key |
| Protected prompt labels | Not listed as included, confirm in the license key docs | Included with a valid key |
| Data retention policies | Not listed as included, confirm in the license key docs | Included; policies keep deleting expired data even if the key is removed |
| Audit log viewer | Not listed as included, confirm in the license key docs | Included with a valid key; unavailable if the key is removed |
| Server-side data masking | Not listed as included, confirm in the license key docs | Included; stops for new events if the key is removed |
| UI customization | Not listed as included, confirm in the license key docs | Included with a valid key |
| Organization creators and org management API with SCIM | Not listed as included, confirm in the license key docs | Included; SCIM and org management API return 403 if the key is removed |
| Instance management API | Not listed as included, confirm in the license key docs | Included; returns 403 if the key is removed |
License, support and update terms for each edition
Both editions run the same codebase and the same self-hosted infrastructure, so the differences sit in the license, the support contract and how billing is arranged. The cards below cover what each term covers, what it does not cover, and what to confirm in writing before you buy or deploy.
MIT Expat license for core code
Code outside the ee directories is MIT Expat licensed, so the core platform can be self-hosted, modified and run in your infrastructure without a commercial license. Remember that the license covers the code, not the support. If your team needs a named contact or a vendor SLA, that comes from a separate Enterprise agreement, not from the license itself. Confirm the exact license text against the repository before your legal review.
Separate license for ee directories
The ee, web/src/ee and worker/src/ee directories fall under a separate enterprise license. Features built there, including the ones unlocked by LANGFUSE_EE_LICENSE_KEY, are governed by that agreement. Ask legal to map which code paths your deployment touches and confirm that the enterprise terms cover your intended use, including any internal redistribution or modification of those directories.
Named lead support engineer
The Enterprise plan adds a named lead support engineer, so your team has one assigned contact rather than a general queue. This matters most for teams that must escalate production trace-ingestion problems during business hours. Open source users rely on community support. Ask the vendor who the named engineer is, how they are reached and what hours they cover.
Solutions architect during rollout
Enterprise includes solutions architect support during rollout, which helps with sizing, topology and the ClickHouse, PostgreSQL and blob storage design. It is most useful when you are deploying Langfuse for many teams or planning Kubernetes production. Teams with in-house platform engineers may not need it. Ask what the rollout engagement covers, how long it runs and whether it is included or billed separately.
Support SLA and compliance reports
The Enterprise plan adds a support SLA and SOC 2 Type II and ISO 27001 reports. These reports describe the vendor's own controls, so they help your vendor risk review but do not certify your self-hosted deployment. Request the current report copies under NDA and check their scope, period and any carve-outs against your own control mapping.
Billing through marketplace or invoice
Enterprise can be billed through AWS Marketplace or by invoice, which affects how procurement, committed spend and cloud cost allocation work. Note that Enterprise is custom priced and also bundled with ClickHouse commercial plans, so the ClickHouse fees sit on top. Ask for one written quote covering both vendors and clarify how each renews.
Updates within a major version
Updates within a major version are non-disruptive in both editions, and database migrations run automatically at startup. Major upgrades, such as v3 to v4, follow dedicated migration guides in both editions, so support tier does not change the upgrade path itself. Plan for ClickHouse 25.12 or later for v4 and budget disk headroom for backfills. Test upgrades in a staging environment first.
What breaks when the license key is removed
If you remove the Enterprise key from a self-hosted Langfuse deployment, the core platform keeps running. Per the Langfuse license key documentation, all core features and APIs remain available in the MIT-licensed open source version without limits, so tracing, prompt management and evaluations continue to work. What stops is the set of controls that the key unlocks. The organization management API, SCIM and the instance management API return 403. The audit log viewer becomes unavailable. Server-side data masking stops applying to new events. Project-level RBAC roles, protected prompt labels and UI customization also depend on the key, so plan for those changes as well when you assess a removal.
The two consequences that need planning before any key change are retention and masking. Existing data retention policies keep deleting expired data after the key is removed, so a policy you configured under Enterprise continues to remove records on schedule. Masking is different: it stops for new events, which means traces ingested after removal may carry values that were previously redacted. Before you rotate, downgrade or let a key lapse, export the current retention settings, confirm which projects rely on masking, and decide whether ingestion must be paused or redirected until masking is restored in your environment.
Run a short check in a non-production instance before the change. Confirm that LANGFUSE_EE_LICENSE_KEY is set consistently on both the web and worker containers, because the key is activated there. Then test whether SCIM provisioning, the organization management API and your audit review process fail as expected, and record which internal teams or automations call those endpoints. Ask your Langfuse account contact to confirm how the key behaves during renewal and what the recommended sequence is for your deployment. For the full feature list tied to the key, read the Langfuse license key documentation.
When the paid edition is worth it, by team situation
A single team evaluating or running Langfuse for internal use usually gets everything it needs from the MIT-licensed edition. The Langfuse license key documentation states that all core features and APIs are available in the open source version without limits, and that self-hosted deployments run the same infrastructure as Langfuse Cloud with no scalability limits between versions. The paid features cover administration, governance and vendor support, so they only matter once one of those needs appears.
- Core tracing and evaluation: tracing, prompt management and the core APIs stay in the MIT edition with no license key.
- Project-level RBAC: this needs a key, so a small team sharing one project does not need it.
- Support: the free plan includes community support only, so the team relies on public channels and its own runbooks.
- Upgrades: minor updates within a major version apply database migrations at startup, so the team still needs a test environment for major upgrades.
- Cost driver: the main cost is the infrastructure and the engineer time to operate it, not a license fee.
Check whether the team's internal use stays within one project and one group of users before assuming the MIT edition will last.
An organization with several teams sharing one Langfuse instance needs separation between those teams. Project-level RBAC roles, audit logs and the organization management API are Enterprise features that need a key, according to the Langfuse license key documentation. These matter when different groups must see different projects, when someone must prove who changed what, or when administrators must manage many organizations from code.
- Project-level RBAC roles: they restrict what each team can view or change inside a project, and they need the Enterprise key.
- Audit logs: they record administrative activity, and the audit log viewer becomes unavailable if the key is removed.
- Organization management API: it supports automated administration of organizations, and it returns 403 without a valid key.
- Organization creators: this Enterprise feature controls who can create new organizations.
- Condition: if one team's data is never visible to another, a shared MIT instance may still be enough.
Confirm with the vendor which roles and audit events the key enables in your version before you rely on them for separation of duties.
Regulated teams often need to limit how long trace data lives and to hide sensitive values before they are stored. The Enterprise key unlocks data retention policies and server-side data masking. The licensing documentation also describes what happens if the key is removed: existing retention policies keep deleting expired data, but masking stops for new events. That asymmetry is important for compliance design, so teams should plan around it rather than assume a key removal is harmless.
- Data retention policies: they delete expired data on a schedule, and they keep working after the key is removed.
- Server-side data masking: it hides sensitive fields during ingestion, and it stops for new events if the key is removed.
- SCIM provisioning: it lets an identity provider create and remove users automatically, which supports joiner and leaver controls.
- Operational proof: the team must still prepare evidence, since DeployOpen prepares controls and evidence but auditors issue any report.
- Vendor reports: the Enterprise tier lists SOC 2 Type II and ISO 27001 reports, which you should request directly from the vendor.
Before relying on masking, test it on sample traces and confirm the key handling process with your compliance lead.
Some organizations choose the Enterprise tier for vendor support rather than for extra product features. The self-hosted pricing page lists a named lead support engineer, solutions architect support during rollout, a support SLA and billing through AWS Marketplace or invoice. The cost is custom, so the decision depends on how much the organization values a guaranteed response path compared with the internal staff time it would otherwise spend.
- Named lead support engineer: a single point of contact for the deployment.
- Solutions architect support during rollout: useful when the first production deployment is large or the team is new to ClickHouse.
- Support SLA: the pricing page lists one, but the response times are in the contract, so request them in writing.
- Billing channel: AWS Marketplace or invoice, which affects procurement paths.
- Recurring cost: the license is recurring and sits on top of the ClickHouse commercial plan, so budget both.
Ask the vendor for the SLA terms, the scope of the solutions architect time and how the key is delivered before signing.
What you pay for in each edition
This table lists who is paid for each cost component in self-hosted Langfuse, under the MIT edition and under Enterprise. Read the recurring rows first, because infrastructure and operations stay with you in both editions, and the Enterprise subscription and ClickHouse plan are added on top.
| Cost component | Open source (MIT) | Enterprise (self-hosted) |
|---|---|---|
| Infrastructure for web, worker and PostgreSQL | You pay your cloud or data center provider for the containers and database you run. Recurring, scales with trace volume and users. | Same as open source. Recurring. Enterprise does not change the sizing of these components. |
| ClickHouse, Redis or Valkey and blob storage | You pay for the ClickHouse nodes, cache and S3-compatible storage. Recurring, and ClickHouse disk needs grow with ingestion and retention. | Same infrastructure cost if you run it yourself. If you buy ClickHouse Cloud, BYOC or Private, the ClickHouse plan is a separate commercial contract. |
| Langfuse Enterprise subscription | Not applicable. The MIT edition has no license key cost. | Custom pricing. Recurring under the agreed term. No figure is published, so request the subscription price in writing. |
| ClickHouse commercial plan | Not applicable unless you choose a ClickHouse managed option for your own use. | Enterprise is bundled with ClickHouse Cloud, BYOC or Private and priced on top of the ClickHouse commercial plan. Recurring. Confirm which plan and term apply. |
| Initial implementation and migration | Your team or a partner sets up Compose or Helm, backups and upgrades. One-time for setup, then recurring for upgrades. | Same setup work. Ask whether rollout support, such as a solutions architect, is included in the subscription or billed separately. |
| Internal operations effort | Ongoing staff time for upgrades, including major migrations such as v3 to v4, monitoring, backups and on-call. Recurring. | Same effort, plus time to manage the license key on web and worker and to track the limited license compliance telemetry. Recurring. |
| What to request in a written quote | Scope, sizing for each component, backup and upgrade responsibilities, and the named staff involved. | Subscription price and term, what is billed through the ClickHouse plan, support level and SLA, named support roles, and billing route such as invoice or AWS Marketplace. |
How Enterprise is now bundled with ClickHouse commercial plans
The Enterprise offering for self-hosted Langfuse is no longer a standalone purchase in the way many teams expect. Langfuse's self-hosted pricing page places Enterprise inside bundles with ClickHouse Cloud, ClickHouse BYOC or ClickHouse Private, and prices it on top of the ClickHouse commercial plan. In practice, the Langfuse Enterprise cost sits alongside a ClickHouse contract you must also sign, so the total is not a single line item. Before you compare quotes, confirm with both Langfuse and ClickHouse which party invoices what, whether the bundle is billed through one contract or two, and whether AWS Marketplace billing applies to either side.
Sizing is the second point to pin down. Langfuse's scaling guide lists 2 CPU and 8 GiB as a minimum for ClickHouse, with at least 16 GiB of memory for larger deployments, and the v3 to v4 upgrade guide advises about 3x ClickHouse disk headroom when backfilling historic data. Ask whether the ClickHouse tier in the bundle is sized for your ingestion volume and retention window, who decides when to scale it up, and whether a larger ClickHouse plan changes the Langfuse Enterprise price. Those answers determine whether the bundle is cheaper than running ClickHouse yourself or simply moves the bill.
If your organization already runs ClickHouse for other analytics, ask how the Langfuse tables would share that cluster, what isolation and backup responsibilities fall to your team, and whether the bundled plan covers only the Langfuse workload. Also confirm what happens to the Enterprise subscription if you later move the ClickHouse deployment to a different option, since a change of ClickHouse plan may require re-quoting the Langfuse key. Write these terms into the quote so the switching cost is known before you commit.
Moving from the MIT edition to Enterprise, and back
This sequence shows how a team activates the Enterprise key on an existing self-hosted Langfuse stack, confirms the gated features work, and what changes if the key is later removed.
Obtain the Enterprise license key through Langfuse
Your team starts by requesting an Enterprise license key from Langfuse, which is a commercial step tied to the custom-priced Self-Hosted Enterprise plan. Procurement, the platform owner and whoever signs the Langfuse commercial terms are involved here, and the scope of support included in that plan should be confirmed in writing before you proceed. The step is done when your team holds the key and has stored it in your secrets manager rather than in a repository or plain configuration file. Ask Langfuse which billing route applies, since the pricing page lists invoice, AWS Marketplace and ClickHouse-bundled options.
Set LANGFUSE_EE_LICENSE_KEY on web and worker
The platform engineer adds the LANGFUSE_EE_LICENSE_KEY environment variable to both the Langfuse web container and the worker container. Setting it on only one container is a common gap, so the change should be reviewed in both deployment manifests, whether you run Docker Compose or the Helm chart. Note that enterprise self-hosted deployments send limited telemetry for license compliance, so your security team should review that behavior before rollout. The step is complete when both container definitions show the variable and the change is recorded in your configuration management system.
Restart web and worker and confirm startup
The operator restarts the web and worker containers so they read the new environment variable. Restarting is a configuration change only; core features run the same under the MIT edition, and the Enterprise features are gated at runtime by the key. Check the container logs for a clean startup and confirm no migration errors appear. Updates within a major version apply database migrations automatically at startup, so a restart at the same version should not change the schema. The step is complete when both containers are healthy and the web UI loads for an administrator account.
Verify RBAC roles and audit log access
A project owner and an administrator test the gated features in a non-production project first. Confirm that project-level RBAC roles can be assigned and that the audit log viewer opens for an administrator, since the viewer is unavailable without the key. Also check that protected prompt labels behave as your governance design expects. Record the results in your change ticket so the evidence exists for later review. The step is complete when each gated feature has been exercised by an account with the intended role and the results are documented.
Review retention and server-side masking settings
The privacy or compliance lead and the platform engineer review data retention policies and server-side data masking configuration against your data handling rules. Retention policies are a gated feature, and the settings should be confirmed before real traces flow through the instance. Masking applies to new events, so verify it with test data that resembles production content. Confirm with Langfuse what masking covers in your version. The step is complete when the retention and masking settings match a signed-off written standard and a test trace shows the expected behavior.
Plan the reverse path before you need it
If the key is later removed, core OSS features keep working, but the organization management API, SCIM and instance management API return 403, the audit log viewer becomes unavailable, server-side masking stops for new events and existing retention policies keep deleting expired data. Before activation, document who owns each of those consequences, which identity provisioning flows depend on SCIM, and whether any compliance evidence depends on audit log exports. The step is complete when the team has a written contingency that names the affected integrations and owners.
Run major upgrades under their own migration guides
Edition does not change upgrade rules. Updates within a major version are non-disruptive and migrate automatically at startup, while major upgrades such as v3 to v4 follow dedicated migration guides regardless of whether the key is present. The v3 to v4 guide requires ClickHouse 25.12 or later, PostgreSQL 15 or later and Redis 7.0 or later, and it advises about 3x ClickHouse disk headroom when backfilling historic data. Confirm current requirements in the guide before scheduling. The step is complete when the upgrade plan references the matching guide and the required component versions are confirmed.
Questions buyers ask before choosing an edition
Does the MIT edition of Langfuse have usage limits?
No. Langfuse states that all core features and APIs are available in the MIT-licensed open source version without limits, and that self-hosted deployments use the same codebase and infrastructure as Langfuse Cloud with no scalability limits between versions. The features that need a license key are a specific list: project-level RBAC roles, protected prompt labels, data retention policies, audit logs, server-side data masking, UI customization, organization creators, the organization management API with SCIM, and the instance management API. Check that list against your own requirements before you assume you need Enterprise. Confirm current terms on the Langfuse license key page.
Which features make a self-hosted Langfuse team need the Enterprise key?
The key is needed only when you rely on one of the gated features. Common triggers are per-project access control through RBAC roles, retention rules that delete traces on a schedule, an audit trail of administrative actions, masking sensitive fields on the server before storage, and identity provisioning through SCIM. A team that only runs tracing, evaluations and prompt management for internal use may not need any of them. Map each control your auditor or security team asks for to the gated list before buying anything.
How much effort does self-hosting the core Langfuse stack take?
The effort comes from running six components: the Langfuse Web and Worker containers, PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible blob storage. 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. The scaling guide lists minimums of 2 CPU and 4 GiB for web, worker and PostgreSQL, 1 CPU and 1.5 GiB for Redis or Valkey, and 2 CPU and 8 GiB for ClickHouse, with at least 16 GiB of ClickHouse memory for larger deployments. Treat these as starting points. Ingestion volume, retention and concurrency decide the real sizing.
What does the internal team need to run Langfuse after go-live?
Plan for owners of each layer: someone to operate Kubernetes or the VM, someone to run PostgreSQL and ClickHouse backups and capacity, someone to manage object storage and secrets, and someone to watch application health. Langfuse says minor updates within a major version are non-disruptive and run database migrations automatically at startup, which reduces routine work. Major upgrades follow dedicated guides, so each one needs a planned change window and a tested rollback. Confirm internally who holds the on-call duty and who approves upgrades before the first deployment.
Can a team upgrade a self-hosted Langfuse deployment to v4 without outside help?
A capable platform team can, if it follows the official guide closely. The v3 to v4 guide requires ClickHouse 25.12 or later (26.4 recommended), PostgreSQL 15 or later and Redis 7.0 or later. It moves the data model to observations first and advises about 3x ClickHouse disk headroom when backfilling historic data, which is the step most likely to surprise a team. Test the upgrade on a copy of production data, measure disk and time, and only then schedule the cutover. An outside partner can carry out that rehearsal under a written scope if your team lacks the time.
What does DeployOpen do in a fixed-scope Langfuse engagement?
DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms inside your own cloud accounts, data centers or air-gapped networks. For Langfuse, a typical written scope could cover the deployment architecture, the six-component installation, identity and SSO integration, backup and restore testing, the upgrade plan and the runbooks your operators will use. Scope, deliverables and timelines are agreed in writing before work starts. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications. Ongoing support and upgrades are available as retainers.
How should we ask for a quote for self-hosted Langfuse?
Send a written description of the outcome, not a list of product names. Include the number of projects and users, the expected trace volume, the retention periods you need, which Enterprise features you require, the target clouds or data centers, your identity provider, your backup and recovery targets and any compliance evidence you must produce. Ask the vendor separately for Enterprise pricing and what it bundles, since Langfuse lists Enterprise at custom pricing and notes it is priced on top of ClickHouse commercial plans when bundled with ClickHouse. DeployOpen does not publish a price list, and a quote follows from the written scope.
How DeployOpen scopes Langfuse deployments on either edition
DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms inside the client's own cloud accounts, data centers or air-gapped networks. For Langfuse, that work usually runs under a fixed-scope agreement in which scope, deliverables and timelines are written down before work starts, and DeployOpen quotes from that written scope. DeployOpen does not publish a price list, so the reader should not expect a rate card here. What drives the quote is the environment, the number of projects and users, the ingestion volume and which controls the client needs to see evidenced.
The scope differs by edition. On the MIT edition, a typical scope covers deploying the web and worker containers with PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible blob storage, sizing those services against Langfuse's scaling guidance, configuring backups and upgrade runbooks, and documenting the setup. On the Enterprise edition, the scope can also include configuring LANGFUSE_EE_LICENSE_KEY on both containers, setting up project-level RBAC, retention policies, masking and SCIM provisioning, and collecting audit log evidence for the client's assessors. Ask for the scope to name which of these items are in and which stay with the client's own team.
DeployOpen is not Langfuse, ClickHouse or any other vendor named on this page. Licensing terms, Enterprise pricing, support SLAs and the ClickHouse commercial plan that bundles Enterprise come from those vendors, and DeployOpen cannot change them. Before signing, confirm with Langfuse and ClickHouse which entitlements apply to your deployment model, and confirm in writing which vendor support obligations sit with the vendor and which sit with DeployOpen. Read the Langfuse license key documentation before you finalize the scope, because it defines the features that depend on the key.
How DeployOpen delivers and supports either edition
DeployOpen plans, implements, hardens, documents and supports self-hosted platforms inside your own infrastructure, so the edition choice is handled as a scoped decision rather than a default. Whether you run the MIT edition or add an Enterprise license key, the work follows the same written scope, build and handover steps.
How we scope
- Engagements are fixed-scope, with the edition, deployment target and feature list agreed in writing before work starts.
- The written scope names which Enterprise features, if any, need a license key, such as RBAC, retention, audit logs, masking or SCIM.
- Scope also records who holds the license key and which containers receive the LANGFUSE_EE_LICENSE_KEY variable.
How we build
- We deploy the web and worker containers with PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage inside your environment.
- Where a license key is in scope, we configure and test it on both web and worker containers, and check the behavior of gated features.
- We test the removal path too, confirming that core features keep working and that gated endpoints and the audit log viewer behave as documented.
How we hand over
- You receive runbooks covering the edition in use, the license key location and the steps for rotating or removing it.
- Documentation records which features depend on the key, so compliance and security teams can map controls to actual behavior.
- Upgrade guidance covers within-major updates and the dedicated migration guides for major versions, scoped as separate work when needed.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the initial build.
- Ask any provider, including us, to confirm in writing what support level, response commitments and telemetry terms apply to your edition.
- Confirm with Langfuse which support tier, SLA and reports it offers for Enterprise, because those terms come from the vendor, not from DeployOpen.
