When Langfuse on Docker Compose is enough and when Kubernetes is the better fit
Docker Compose is enough for evaluation, local testing and proofs of concept. Kubernetes with the Langfuse Helm chart is the path to choose for production. Langfuse's self-hosting overview describes Compose as a single VM for local use and testing, without high availability, scaling or backups, and lists Kubernetes (Helm), AWS, Azure and GCP for production self-hosting. Compose is therefore not a production target by Langfuse's own description, even though it runs the same six components: the web and worker containers, PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible blob storage.
Compose fits when a small team needs to see traces end to end, test SDK or OpenTelemetry instrumentation, or validate a Langfuse version before a rollout, and when losing the VM would only cost re-running tests. Kubernetes fits when the stack must survive a node failure, scale the worker or split langfuse-web into ingestion and user interface deployments under heavy load, or sit inside an existing cluster with its own backup, policy and access controls. Langfuse's scaling guide also asks for at least 2 CPU and 4 GiB for web, worker and PostgreSQL, and 2 CPU and 8 GiB for ClickHouse, so a single VM sized for those minimums is a test environment, not a capacity plan.
Before choosing, confirm three things with your platform team: who will operate Kubernetes and the ClickHouse operator, whether your clusters meet the Kubernetes 1.28 requirement for that operator, and whether you will point the chart at managed PostgreSQL, Redis and object storage, which Langfuse recommends for production. If the answer to all three is no, a managed Langfuse service or a Compose trial with a documented migration plan may be the more honest first step. Ask DeployOpen or any implementer to put the chosen path in writing, with backup and restore responsibilities named, before any data flows in.
Which deployment fits your team's situation
A proof of concept usually needs to answer one question quickly: does Langfuse capture the traces, scores and prompts your application produces? Langfuse documents Docker Compose on a single VM for local use and testing, and describes that setup as having no high availability, scaling or backups. For this stage, that trade-off is usually acceptable, and it keeps the number of moving parts low.
- Deciding factor: downtime tolerance is high, because nothing downstream depends on the instance yet.
- Effort: one VM, one Compose file, and the six components (web, worker, PostgreSQL, ClickHouse, Redis or Valkey, object storage) running together.
- Skills: a team comfortable with containers can stand this up without Kubernetes experience.
- Exit path: confirm that the data you create in the test can be discarded, or that you have a documented export before you invest further.
- Upgrade path: plan for the major-version migration guides, since a test instance is often the first place teams meet a v3 to v4 change.
Before you commit, confirm which features your evaluation needs and whether any of them require an Enterprise license key on the self-hosted edition. Confirm the hardware sizing against the minimums in Langfuse's scaling guide with the vendor's current documentation.
An internal team running Langfuse for a single application group or a non-critical environment often has real usage but accepts a short maintenance window. Docker Compose on one VM can serve this stage if the team owns backups and restores, but Langfuse's own documentation positions a single VM as lacking high availability, so the team must accept that a host failure stops tracing until the host is restored.
- Deciding factor: whether the team accepts a single point of failure and a manual recovery path.
- Effort: you own host patching, container updates, database backups and the storage for ClickHouse and blob data.
- Skills: Linux administration and container operations, without a dedicated cluster team.
- Existing cluster: if your organization already runs Kubernetes with a platform team, the Helm chart may be cheaper to operate than a bespoke VM.
- Data residency: the VM must sit in the region your data rules require.
Confirm who receives alerts when the host or a container fails, how long a restore takes in your environment, and whether the backup of each data store has been test-restored.
A production platform carries availability, audit and change control expectations. Langfuse documents Kubernetes with Helm or Terraform-based deployments on AWS, Azure and GCP for production self-hosting. The Helm chart bundles data stores by default, but the Langfuse Helm docs recommend managed blob storage such as Amazon S3, Google Cloud Storage or Azure Blob Storage, and allow pointing at existing PostgreSQL, ClickHouse and Redis instances. Kubernetes 1.28 or newer is required for the ClickHouse operator.
- Deciding factor: downtime tolerance and in-house Kubernetes skills, which together decide whether the chart's bundled stores are acceptable or should be replaced with managed services.
- Scope: the cluster, the data stores, backups, restore tests, upgrade sequencing and the Langfuse major-version migrations.
- Audit: access control, retention and audit logs may depend on Enterprise features, which the MIT edition does not include.
- Skills: a platform team that can operate Kubernetes upgrades and secret encryption.
- Cost drivers: managed services, cluster capacity and the staff hours to run them, all of which recur.
Confirm your Kubernetes version support window, your backup and restore targets, and which Langfuse features your audit requirements need before you choose a deployment model.
Docker Compose and Kubernetes side by side for Langfuse
This table compares a single-VM Docker Compose deployment of Langfuse with a Kubernetes deployment using the Langfuse Helm chart, across documented use, availability, backups, upgrades and the skills each one assumes. Read each row as a question to answer for your own environment, and treat the items marked to confirm as open until Langfuse or your platform team has verified them.
| Factor | Docker Compose on one VM | Kubernetes with the Langfuse Helm chart |
|---|---|---|
| Documented use | Local use and testing, per the Langfuse self-hosting overview | Production self-hosting, alongside AWS, Azure and GCP Terraform-based options |
| High availability | Not provided. Langfuse documents the single-VM setup without high availability | Possible in principle, but you design and verify it. Confirm the replica and failover setup with Langfuse |
| Scaling | Limited to the one host. Langfuse recommends scaling worker containers on CPU load, which is harder on one VM | Worker and web replicas can be scaled. Under heavy ingestion, Langfuse suggests splitting web into ingestion and UI deployments |
| Backups | Not covered by the documented Compose setup. You own backups for PostgreSQL, ClickHouse, Redis or Valkey and blob storage | You own backups for every store, whether bundled or external. Confirm backup tooling for the chart's data stores with Langfuse |
| Upgrade path | Minor updates within a major version apply migrations at startup. Major upgrades follow Langfuse migration guides | The chart v1 to v2 upgrade must finish before Langfuse v4, per the Helm docs. Plan this on both paths |
| Components the team runs | All six: web, worker, PostgreSQL, ClickHouse, Redis or Valkey, and object storage, on one host | The chart can bundle PostgreSQL, Valkey, ClickHouse via its operator and SeaweedFS. Production guidance favors managed stores you point at |
| Required skills | Docker, Compose, Linux host hardening, backup and restore for each store | Kubernetes operations, Helm, operator management, persistent volumes, network policy and secrets handling |
| Infrastructure assumed | One VM sized for the documented minimums, such as 2 CPU and 4 GiB for web and worker | A cluster running Kubernetes 1.28 or newer for the ClickHouse operator, plus storage classes and ingress |
| Confirm before choosing | Whether one host meets your recovery and maintenance windows with Langfuse and your team | Who owns the cluster, the ClickHouse operator and each data store's backup and restore testing |
What the six components do and where each one runs
Every self-hosted Langfuse deployment runs the same six components, whether on one VM or in a cluster. The choice between Docker Compose and Kubernetes changes where they run, who keeps them alive and how much headroom each one gets.
Langfuse web
The web container serves the Langfuse UI and its APIs, and it receives trace ingestion from your applications. Its documented minimum is 2 CPU and 4 GiB of RAM. Under heavy ingestion, Langfuse recommends splitting web into separate ingestion and user interface deployments, which is simpler to plan on Kubernetes than on one VM. Check that your sizing covers both ingestion traffic and dashboard users.
Langfuse worker
The worker processes events asynchronously, so ingestion does not wait on database writes. Langfuse recommends scaling worker containers on CPU load, which makes the worker the natural first component to add replicas to. On Compose you scale it by hand on the same VM, while on Kubernetes you set a replica count and autoscaling rules. Confirm that worker capacity keeps pace with your peak trace volume.
PostgreSQL
PostgreSQL holds transactional data such as users, projects, prompts and configuration, separate from the trace store. The documented minimum is 2 CPU and 4 GiB of RAM. Compose runs it in a container on the same VM, so a disk failure takes it down with everything else. For production, plan a managed PostgreSQL service with backups and failover, and confirm it is version 15 or later, which the v4 upgrade requires.
ClickHouse
ClickHouse stores traces, observations and scores, and it is the component that drives most of your memory and disk planning. The documented minimum is 2 CPU and 8 GiB of RAM, and Langfuse advises at least 16 GiB of ClickHouse memory for larger deployments. The v4 upgrade requires ClickHouse 25.12 or later, and backfilling historic data needs about 3x disk headroom. Ask who patches and backs up ClickHouse before you choose a runtime.
Redis or Valkey
Redis or Valkey handles queues between web and worker and provides caching. The documented minimum is 1 CPU and 1.5 GiB of RAM, which makes it the lightest stateful component. Compose can run it as a container, but a queue that loses its contents during a restart is a risk you should size for. Confirm the version meets the Redis 7.0 or later requirement for v4, and decide whether a managed instance fits your network rules.
Object storage
S3-compatible blob storage receives incoming events and holds exports, so it is the component where data residency decisions show up first. The Langfuse Helm chart bundles SeaweedFS for object storage by default, but the Helm docs recommend a managed service such as Amazon S3, Google Cloud Storage or Azure Blob Storage for production. Compose can point at an existing S3-compatible bucket. Confirm the bucket's region, encryption and retention settings with your compliance owner.
What the Langfuse Helm chart bundles and what to move to managed services
The Langfuse Helm chart deploys the application and its data stores by default, so a first install on Kubernetes gives you a working stack without wiring up databases yourself. Since chart v2.0.0, the bundled dependencies are PostgreSQL, Valkey, ClickHouse through the ClickHouse Kubernetes Operator, and SeaweedFS for object storage. Earlier chart versions used Bitnami sub-charts, which v2.0.0 replaced with OSS-licensed alternatives. Before you adopt the defaults, confirm which of these components your platform team will accept running in the cluster, who patches them, and who restores them after a failure. Those answers decide whether the bundled stack is a starting point or the production design.
Langfuse's production guidance points the other way. It recommends managed blob storage such as Amazon S3, Google Cloud Storage or Azure Blob Storage instead of the bundled object store, and it lets you point the chart at existing PostgreSQL, ClickHouse and Redis instances. Moving state to services your cloud provider or database team already operates shifts backups, patching and high availability to people who run those services every day. The trade-off is a larger set of external dependencies to secure, network and budget for. Ask whether your ClickHouse will be self-managed or bought as a managed service, since that choice drives most of the operating effort. The ClickHouse operator also requires Kubernetes 1.28 or newer, so check the cluster version against that minimum before you plan the install, and check the Langfuse Kubernetes Helm documentation for the current chart requirements.
Treat the bundled ClickHouse as the component to scrutinize first. Langfuse's v4 requirements call for ClickHouse 25.12 or later, and the v1 chart cannot bring its bundled ClickHouse to the version v4 needs, so the chart v1 to v2 upgrade must be finished before any move to Langfuse v4. Plan backups and restore tests for ClickHouse and PostgreSQL in either case, because replication alone does not protect against human error or corruption. Whether you keep the bundled stores or point at managed ones, write down who owns each data store, its backup schedule and its restore test, and confirm the recovery steps against a spare environment before go-live.
How to move from a Compose trial to a production Kubernetes deployment
This sequence turns a single-VM Compose trial into a Kubernetes deployment whose data stores, upgrade path and recovery steps are agreed and tested before any real traces arrive.
Validate the trial on representative data
Run the Compose stack with a sample of the traces, observations and scores you expect in production, including the largest payloads and the query patterns your team uses in the UI and API. Your platform or security team owns this step, and the Langfuse engineers you work with can review the findings. It is done when you have written down ingestion volume, query latency you accept, and which features you depend on, including any that need an Enterprise license key. Those notes become the requirements for the cluster.
Size the cluster and data stores
Use the minimum resources in the Langfuse scaling guide as a floor, then size against the trial numbers. Confirm the Kubernetes version your platform team supports is 1.28 or newer, since the Langfuse Helm docs require it for the ClickHouse operator. Decide who runs the control plane, node pools, etcd backups and patching, because the cluster carries this load after go-live. It is done when a written sizing record and an owner for each component exist, and the platform team has approved them.
Choose managed or existing data services
Decide, for each dependency, whether to use the chart's bundled service or an existing managed or internal one. The Langfuse Helm docs recommend a managed blob storage service such as Amazon S3, Google Cloud Storage or Azure Blob Storage for production, and they allow pointing the chart at existing PostgreSQL, ClickHouse and Redis instances. Ask your cloud or data team to confirm backup, restore, patching and high availability for each service, since the chart does not provide those on its own. It is done when each component has a named owner and a documented backup method.
Set up ClickHouse replication and backups
If you run ClickHouse yourself, plan ReplicatedMergeTree replication with ClickHouse Keeper. The ClickHouse replication guide recommends at least three Keeper nodes on dedicated hosts in production. Its backup documentation notes that replication does not protect against human error or corruption, so schedule BACKUP and RESTORE jobs to separate storage. Restore a backup on a spare cluster before go-live, because the ClickHouse backup documentation warns that a backup never test-restored will probably not restore properly. It is done when a restore test has succeeded and the result is recorded.
Deploy the chart with pinned values
Install the Langfuse Helm chart into a non-production namespace with values that point at the data services chosen earlier. Keep the values file and the chart version in version control, and store secrets through your approved secrets process rather than plain values. Confirm that Secrets are encrypted at rest in etcd, since Kubernetes stores them unencrypted by default, and that RBAC limits who can read them. It is done when the web and worker pods are healthy, sign-in works through your chosen authentication method, and a test trace appears in the UI.
Plan the chart v1 to v2 upgrade before v4
If your deployment starts on chart v1, plan the move to v2 before any Langfuse v4 upgrade. The Langfuse Helm docs say the v1 chart cannot bring its bundled ClickHouse to the version Langfuse v4 requires. Read the v3 to v4 guide, which requires ClickHouse 25.12 or later (26.4 recommended), PostgreSQL 15 or later and Redis 7.0 or later, and note its advice about about 3x ClickHouse disk headroom when backfilling historic data. Confirm the ClickHouse version your organization supports against the ClickHouse support policy. It is done when the upgrade order, disk capacity and rollback plan are approved in writing.
Rehearse the upgrade and recovery
Run the planned upgrade on a copy of the non-production data, then practice restoring from backup. Langfuse states that minor updates within a major version apply database migrations automatically at startup, so confirm the timing of that migration against your change windows. Record how long the upgrade and restore took on your own hardware, because published figures will not match your data volume. It is done when the rehearsal produces a runbook your on-call team has read and can follow.
Cut over and hand off to operations
Point your instrumented applications at the Kubernetes endpoint, keep the Compose stack available for a defined fallback period, and monitor ingestion, storage growth and pod restarts. Ask your operations team to confirm alert routing and the on-call owner for each component. Decide, with your security team, which Enterprise features you need, and check whether a license key is required before enabling them. It is done when the Compose stack is retired or archived and the runbook, owners and monitoring are in your operations system.
Upgrades, backups, monitoring and skills for each option
This table compares who handles upgrades, backups, monitoring and Kubernetes maintenance under each option. Read it as a list of day-two duties: the Compose path keeps them on one VM and in your hands, while the Helm path adds cluster lifecycle work on top of the same data stores.
| Area | Docker Compose on one VM | Kubernetes with the Langfuse Helm chart |
|---|---|---|
| Minor upgrades within a major version | Pull the new image and restart. Langfuse applies database migrations automatically at startup, so plan a window and a rollback copy of the data first. | Upgrade the chart and image values in a staging release first. Migrations also run at startup, but a bad rollout is handled by the cluster, so test the values file before promoting. |
| Major upgrades (v1 to v2, v2 to v3, v3 to v4) | Follow the dedicated Langfuse migration guide for each step. The v3 to v4 guide requires ClickHouse 25.12 or later and PostgreSQL 15 or later. | Same migration guides apply. The Helm docs say the chart v1 to v2 upgrade must be completed before moving to Langfuse v4, because the v1 chart cannot bring its bundled ClickHouse to the required version. |
| PostgreSQL backups | Your team owns the dump or snapshot schedule, retention and restore tests on the VM or its attached volume. | Owned by you when the chart points at an existing PostgreSQL instance. If you use the bundled database, confirm its backup approach with the chart documentation. |
| ClickHouse backups | Your team runs BACKUP and RESTORE to local disk, S3-compatible storage or Azure Blob Storage. Replication is not used on a single VM, so backups carry the recovery burden. | Same BACKUP and RESTORE tooling, plus ReplicatedMergeTree replication coordinated by ClickHouse Keeper. ClickHouse documents that replication alone does not protect against human error or corruption, so backups stay necessary. |
| Blob storage backups | Owned by your team. Confirm versioning or replication settings on the bucket you use for incoming events and exports. | Use managed blob storage for production as the Helm docs recommend. Bundled SeaweedFS storage needs its own backup and durability plan. |
| Restore testing | Schedule restore tests on a spare host. ClickHouse warns that a backup never test-restored will probably not restore properly when needed. | Restore into a separate namespace or cluster on a schedule. Include etcd snapshot restores for the cluster itself if you run your own control plane. |
| Monitoring | Watch container health, disk headroom for ClickHouse and worker backlog on one host. Langfuse scaling guidance points to CPU load on workers as the scaling signal. | Monitor pods, ClickHouse replicas and Keeper nodes, plus worker CPU for scaling. Confirm the metrics and alerting stack with your platform team before go-live. |
| Kubernetes version support and skew | Not applicable. The host OS and Docker Engine follow their own update cycle. | Kubernetes releases about three times per year, and the project maintains the three most recent minor releases (1.37, 1.36 and 1.35 as of September 2026). kube-apiserver must be upgraded one minor version at a time, and kubelets may trail by up to three minor versions. |
| Skills your team needs | Linux administration, Docker Compose, PostgreSQL and ClickHouse backup and restore. | All Compose skills plus Kubernetes operations, Helm, RBAC, etcd and node upgrades, and ClickHouse Operator management. |
What drives the cost of running Langfuse on each option
The main cost of self-hosting Langfuse is not the software, which is MIT licensed for the core features, but the infrastructure and the people who run it. On Docker Compose, you pay for one VM sized for the web, worker, PostgreSQL, ClickHouse, Redis or Valkey and blob storage containers, with ClickHouse the largest consumer. The Langfuse scaling guide lists minimum resources 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. On Kubernetes, the same workloads sit on a cluster you must also run, so the control plane, node pools, load balancing and storage add recurring infrastructure cost before any Langfuse component is deployed. Confirm your cloud provider's rates for these components yourself, since Langfuse does not publish them.
Setup cost is mostly skilled labor. Compose needs someone who can size the VM, wire the containers and secure the network, and it has no high availability, so a single-VM build is a testing or low-stakes choice. Kubernetes adds the cluster itself, which Kubernetes 1.28 or newer is required for the ClickHouse operator, plus etcd backup, certificate and secrets handling and RBAC work. Recurring operations are where the gap widens: each Langfuse major upgrade (v1 to v2, v2 to v3, v3 to v4) follows its own migration guide, and the v3 to v4 guide requires ClickHouse 25.12 or later and advises about 3x ClickHouse disk headroom when backfilling historic data. ClickHouse backups must be restore-tested on spare clusters, since a backup never test-restored will probably not restore properly.
Decide early whether you need Enterprise features. Project-level RBAC roles, audit logs, data retention policies, server-side data masking, the org management API with SCIM and the instance management API all require a Self-Hosted Enterprise license key, and this applies on either deployment method. Langfuse lists a custom-priced Self-Hosted Enterprise plan that adds a named support engineer, solutions architect access and a support SLA, but it does not publish a price. Ask the vendor for a written quote covering the license, support tier and any ClickHouse commercial terms, and ask what changes if the key is removed, since that determines how hard a later upgrade decision will be.
Questions teams ask before self-hosting Langfuse on Kubernetes
Can Docker Compose run Langfuse in production?
Langfuse's own self-hosting overview lists Docker Compose for local use and testing and describes it as a single VM without high availability, scaling or backups. It names Kubernetes with Helm, AWS, Azure and GCP for production self-hosting. A Compose stack can still be hardened and backed up by your team, but the vendor guidance places it outside the production path. Confirm with your own availability, recovery and ingestion requirements before you decide. The Langfuse self-hosting overview lists the supported deployment paths.
What does Kubernetes add in skills and effort over Compose?
Kubernetes adds a cluster you must operate, plus the skills to run it. A production cluster brings ingress, persistent volumes, secrets handling, upgrades and monitoring, and a control plane that needs its own high availability design. Kubernetes releases roughly three times a year, and the project supports only the three most recent minor versions, so your team must plan upgrades on that cadence. The ClickHouse operator also needs Kubernetes 1.28 or newer. Engineers who already run clusters absorb this more easily than teams new to Kubernetes.
How long does a Langfuse Kubernetes setup take, and what drives it?
No supplied source gives a reliable setup duration, so confirm timelines in a written scope rather than relying on a generic figure. The main drivers are whether you reuse existing PostgreSQL, ClickHouse, Redis or blob storage or deploy them through the chart, how many clusters and environments you run, your identity and network integration, your backup and restore testing, and whether you need the Enterprise features. Ask your team to list which stores already exist and which need build-out, since that list shapes most of the effort.
Can an internal team run Langfuse on Kubernetes alone?
It depends on the skills you already hold. The team needs Kubernetes operations, database administration for PostgreSQL and ClickHouse, and a tested backup practice. ClickHouse backup documentation warns that a backup never test-restored will probably not restore when needed, and that replication alone does not protect against human error or corruption. The Langfuse v3 to v4 guide requires ClickHouse 25.12 or later, PostgreSQL 15 or later and Redis 7.0 or later, and advises about 3x ClickHouse disk headroom when backfilling. Teams without these skills often bring in a services partner for the build and hand-over, then keep operating the stack internally.
What should a fixed-scope quote for a Langfuse deployment cover?
A useful quote states the deployment target, the components in scope and the environments covered. Ask the partner to name which stores are deployed by the chart and which connect to existing services, how the Langfuse v1 to v2 chart upgrade and later version upgrades are handled, and how backup and restore tests are performed. Also ask about identity and network integration, hardening against your baseline, documentation and hand-over, and what support is excluded. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. Ongoing support is available as a retainer.
Does the Enterprise license key change the Compose or Kubernetes decision?
The key does not decide the platform, but it can affect the deployment choice if you need features it unlocks. Self-hosted Langfuse documents Enterprise-only features including project-level RBAC roles, data retention policies, audit logs, server-side data masking, and the org management API with SCIM. Those features sit behind a license key, while core features and APIs remain available in the MIT-licensed edition. If you need SCIM provisioning or audit logs for compliance evidence, plan that into the environment design and confirm the commercial terms directly with Langfuse. The Langfuse license key documentation explains which features require the key.
Which parts of the Langfuse stack should move to managed services in production?
Langfuse's Helm documentation recommends a managed blob storage service such as Amazon S3, Google Cloud Storage or Azure Blob Storage for production, and it allows pointing the chart at existing PostgreSQL, ClickHouse and Redis instances. Teams often move blob storage first because it holds incoming events and exports and is the simplest to operate as a managed service. Decide on PostgreSQL and Redis or Valkey based on your existing database operations. ClickHouse is the component with the most operational weight, so confirm who will run its upgrades, Keeper nodes and restore tests before you choose between self-run and managed options.
What is the Kubernetes security baseline for a Langfuse deployment?
Start with three controls. Kubernetes stores Secrets unencrypted in etcd by default, so configure encryption at rest and restrict list and watch access with least-privilege RBAC, or use an external store through the Secrets Store CSI Driver. Apply Pod Security Standards to the namespace, and secure the control plane with an odd number of etcd members, with five recommended in production, and a tested etcd snapshot plan. Confirm your identity design against Kubernetes authentication options such as OIDC. Map these controls to your own baseline, such as the CIS Kubernetes Benchmark, and have your assessor verify them.
How to decide between Compose and Kubernetes for your Langfuse rollout
Start with availability. Langfuse documents Docker Compose on a single VM as suited to local use and testing, without high availability, scaling or backups, so if a trace outage would stop a production release gate or an incident review, plan for the Kubernetes path from the start. Next, check what your platform team already runs. A cluster that meets the Kubernetes 1.28 minimum for the ClickHouse operator, with people who can operate it, makes the Helm chart a reasonable default. Without that capacity, a managed Kubernetes service with an external ClickHouse and PostgreSQL may be a better fit than a self-run chart. Confirm which of these your team can staff before comparing quotes.
Then test your operating capacity for the stateful parts. ClickHouse holds traces, observations and scores, PostgreSQL holds transactional data, and Redis or Valkey handles queues. Ask who will own ClickHouse replication, Keeper nodes, backups and restore tests, and whether those skills exist in-house. Write down your data residency and backup rules now, because they decide where blob storage and database backups must live. Your upgrade cadence matters as well: Langfuse major upgrades follow dedicated migration guides, and the v3 to v4 path requires ClickHouse 25.12 or later, so confirm which ClickHouse and Kubernetes lines your platform team can keep current.
Treat the choice as reversible only with a data migration plan. Moving from Compose to a chart, or changing ClickHouse or blob storage later, means exporting and reloading stateful data, so set the target backup and restore procedure before go-live. Whichever path you pick, document the Compose stack or chart values from day one, including image versions, environment settings, storage locations and resource requests, so the next engineer can rebuild the deployment. Confirm with DeployOpen's written scope or your own environment how that documentation and the restore tests will be delivered.
How DeployOpen scopes, delivers and supports a Langfuse deployment
DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For Langfuse, that means choosing between a single-VM Compose stack for testing and a Kubernetes deployment for production, then delivering the chosen design in writing before any build work starts.
How we scope
- We confirm whether the target is a Compose test stack on one VM or a production Kubernetes deployment.
- We list the six components and where each one runs, including managed or existing PostgreSQL, ClickHouse, Redis or Valkey and blob storage.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support is available as a retainer.
How we build
- We deploy Langfuse web and worker, the data stores and blob storage inside your cloud account, data center or air-gapped network.
- We check ClickHouse, PostgreSQL and Redis or Valkey versions against the Langfuse upgrade requirements before the first install.
- We test backups with a restore, not only a backup job, and document the results with the configuration.
How we hand over
- You receive architecture notes, configuration references and the runbook for upgrades, backups and restores.
- We walk your platform and security teams through access controls, secrets handling and the license key decision for Enterprise features.
- Hand-over includes a written record of what was tested, what was left open, and what your team must confirm with vendors.
How we support
- Retainers can cover upgrades, including the Langfuse v3 to v4 path and the ClickHouse version it requires.
- Continuous security testing of the deployment can be added to a retainer, scoped in writing.
- Support scope, response expectations and any SLA are defined in the written agreement, not assumed from this page.
