Overview of Langfuse
mainlangfuse-k8s) specifically provides the Kubernetes deployment infrastructure for the platform.repository·main·Indexed 42 days ago
https://github.com/langfuse/langfuse-k8sKubernetes deployment resources for Langfuse, an open-source LLM engineering platform for observability, metrics, evaluations, and prompt management. Includes a Helm chart and configurations for self-hosting, including ClickHouse authentication, AI feature setup (version >= 4.24), encryption keys, Ingress, and scaling via HPA or KEDA.
langfuse-k8s) specifically provides the Kubernetes deployment infrastructure for the platform.Version 2.0.0 of the Helm chart introduces significant changes by replacing Bitnami sub-charts with OSS-licensed alternatives and using the ClickHouse/clickhouse-operator for ClickHouse deployments.
Component Changes:
| Component | v1.x | v2.0.0 |
|---|---|---|
| PostgreSQL | bitnami/postgresql | groundhog2k/postgres |
| ClickHouse | bitnami/clickhouse | ClickHouseCluster / KeeperCluster (via operator) |
| Redis | bitnami/valkey | valkey-io/valkey |
| Object storage | bitnami/minio | seaweedfs/seaweedfs (allInOne) |
Credential Management:
On first install, the chart auto-generates Secrets for Postgres, ClickHouse, Valkey, SeaweedFS, and three Langfuse application secrets (salt, encryptionKey, nextauth.secret). These are persisted across upgrades via lookup. These Secrets are marked with helm.sh/resource-policy: keep, meaning they survive helm uninstall and must be deleted manually for a clean slate.
If you use bundled stores (*.deploy: true), you must install a sibling v2 release and migrate data while v1 is still serving.
Workflow Overview:
langfuse-v2) with langfuse.ingress.enabled: false. Scale v2 web/worker to 0 replicas initially to allow schema migrations without writing data.mc mirror), and ClickHouse (remote() loop).Upgrading from Langfuse Helm Chart v1.x to v2.0 involves a migration process to handle changes in how data stores (PostgreSQL, ClickHouse) are managed. The migration can be performed using an automated script or manually depending on your storage architecture.
The repository provides scripts to automate the transformation of Helm values and the migration process:
scripts/migrate-v1-to-v2.sh: The main interactive migration driver. Use the --yes flag to skip interactive prompts (it will still print the migration plan).scripts/migrate-values.py: A Python script that transforms v1 values.yaml into v2 formats using one of three modes: sibling, cutover, or inplace.scripts/ch-online-sync.sh: A helper script for performing incremental synchronization of ClickHouse data.To run the automated migration, you must have the following installed:
kubectlhelm >= 3.17jqpython3yq (mikefarah version), PyYAML, or Ruby.v1-values.yaml: A representative example of v1 source values (includes wal_level=logical).v2-values.yaml: An example of a sibling overlay (Ingress is turned off, uses shared app secrets).v2-app-values.yaml: An example of a cutover overlay (Ingress is turned on, uses the same hosts as the original).For new installations, use Helm chart v2.0.0 or later, which ships Langfuse v4 by default. For a quick start, follow the minimal installation guide.
Recommended minimum versions for Langfuse v4:
# Refer to examples/minimal-installation/ for specific commandsBefore installing Langfuse, you must ensure cert-manager and the ClickHouse operator are installed in your cluster. These are required because the Langfuse chart renders ClickHouseCluster and KeeperCluster Custom Resources (CRs). Install them in the following order:
Wait for the CRDs to be established before proceeding to the Langfuse installation.
# 1. Install cert-manager
helm install \
cert-manager oci://quay.io/jetstack/charts/cert-manager \
--version v1.20.2 \
--namespace cert-manager \
--create-namespace \
--set crds.enabled=true
kubectl wait --for=condition=Established \
crd/certificates.cert-manager.io \
crd/issuers.cert-manager.io \
--timeout=120s
# 2. Install ClickHouse operator
helm install clickhouse-operator oci://ghcr.io/clickhouse/clickhouse-operator-helm \
--version 0.0.5 \
--namespace clickhouse-operator --create-namespace
kubectl wait --for=condition=Established \
crd/clickhouseclusters.clickhouse.com \
crd/keeperclusters.clickhouse.com \
--timeout=120sWhen upgrading from Langfuse Helm Chart v0.13 to v1.0, you must restructure your values.yaml. Most core configurations have moved under a top-level langfuse key.
langfuse key.langfuse.image structure. You can now override images per component (web or worker).salt, use langfuse.salt.value or langfuse.salt.secretKeyRef.encryptionKey, use langfuse.encryptionKey.value or langfuse.encryptionKey.existingSecret / existingSecretKey.valkey or additionalEnv to the redis section. Use nameOverride: valkey to keep the old name.clickhouse or additionalEnv to the clickhouse section. Warning: clickhouse configuration and langfuse.additionalEnv ClickHouse variables are mutually exclusive.minio or additionalEnv to the s3 section. Use nameOverride: minio to keep the old name.langfuse.features (e.g., telemetryEnabled, signUpDisabled, experimentalFeaturesEnabled).# Example of the new v1.0 structure
langfuse:
replicas: 1
image:
tag: 3
features:
telemetryEnabled: true
salt:
value: "your-salt"
encryptionKey:
value: "your-key"
redis:
nameOverride: valkey
host: <host>
port: <port>
auth:
username: <username>
password: <password>
clickhouse:
host: <host>
auth:
username: "<username>"
password: "<password>"
s3:
nameOverride: minio
bucket: <bucket>
region: <region>
endpoint: <endpoint>You can bring in data stores from outside the Helm chart by setting their respective *.deploy key to false. This allows you to manage specific components (PostgreSQL, Redis/Valkey, S3-compatible storage, or ClickHouse) independently while letting the chart manage the remaining components.
Overlays are additive: You can combine multiple external component configurations in a single helm install or helm upgrade command, provided their configuration keys do not conflict.
# Example: Installing Langfuse with both external Postgres and external Redis
helm install langfuse . -n langfuse \
-f ../../examples/minimal-installation/values.yaml \
-f ../../examples/external-components/external-postgres.yaml \
-f ../../examples/external-components/external-redis.yamlUse the MinIO Client (mc) to mirror data from the v1 MinIO instance to the v2 SeaweedFS instance.
Sync Process:
mc mirror --overwrite --watch for continuous background syncing.# Set aliases
mc alias set v1 http://langfuse-s3.langfuse.svc.cluster.local:9000 "$V1_KEY" "$V1_SECRET"
mc alias set v2 http://langfuse-v2-s3-all-in-one.langfuse.svc.cluster.local:8333 "$V2_KEY" "$V2_SECRET"
# Sync
mc mb --ignore-existing v2/langfuse
mc mirror --overwrite --watch v1/langfuse v2/langfusemc alias set v1 http://langfuse-s3.langfuse.svc.cluster.local:9000 "$V1_KEY" "$V1_SECRET"
mc alias set v2 http://langfuse-v2-s3-all-in-one.langfuse.svc.cluster.local:8333 "$V2_KEY" "$V2_SECRET"
mc mb --ignore-existing v2/langfuse
mc mirror --overwrite --watch v1/langfuse v2/langfuseIf all your data stores (PostgreSQL, ClickHouse, Redis, Object Storage) are already external (i.e., *.deploy: false in your Helm values), you can perform an in-place upgrade. Service and Ingress names will remain unchanged.
helm upgrade langfuse oci://ghcr.io/langfuse/langfuse-k8s/charts/langfuse \
--version 2.0.0 -n langfuse -f v2-inplace-values.yamlThe migrate-v1-to-v2.sh script automates the migration process, including checking prerequisites, reading v1 values, and migrating bundled components. It asks for confirmation before major steps.
Usage Examples:
Run the standard migration:
./migrate-v1-to-v2.sh --values /path/to/your-v1-values.yamlRun without interactive prompts:
./migrate-v1-to-v2.sh --values /path/to/your-v1-values.yaml --yesPerform a dry run (preflight + generate values only):
./migrate-v1-to-v2.sh --values /path/to/your-v1-values.yaml --dry-runcd examples/upgrade-v1-to-v2/scripts
./migrate-v1-to-v2.sh --values /path/to/your-v1-values.yamlTo migrate PostgreSQL data from v1 to v2 using logical replication, you must first enable logical replication on the v1 Bitnami PostgreSQL instance.
1. Enable logical replication in v1 values:
postgresql:
primary:
extendedConfiguration: |
wal_level = logical
max_wal_senders = 10
max_replication_slots = 102. Create Publication on v1:
kubectl -n langfuse exec langfuse-postgresql-0 -- \
psql -U postgres -d postgres_langfuse -c "CREATE PUBLICATION lf_pub FOR ALL TABLES;"3. Create Subscription on v2: After clearing the v2 database, create the subscription pointing to the v1 host.