Langfuse Kubernetes Deployment

repository·main·Indexed 42 days ago

https://github.com/langfuse/langfuse-k8s

Kubernetes 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.

Tokens
20.3K
Snippets
35
Records
61
Agent score
55%

What's inside Langfuse

  1. Understand breaking changes in Helm chart v2.0.0

    main

    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:

    Componentv1.xv2.0.0
    PostgreSQLbitnami/postgresqlgroundhog2k/postgres
    ClickHousebitnami/clickhouseClickHouseCluster / KeeperCluster (via operator)
    Redisbitnami/valkeyvalkey-io/valkey
    Object storagebitnami/minioseaweedfs/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.

  2. Upgrade Path: Bundled Stores (Sibling + Traffic Shift)

    main

    If you use bundled stores (*.deploy: true), you must install a sibling v2 release and migrate data while v1 is still serving.

    Workflow Overview:

    1. Stand up v2: Install the v2 chart as a sibling release (e.g., langfuse-v2) with langfuse.ingress.enabled: false. Scale v2 web/worker to 0 replicas initially to allow schema migrations without writing data.
    2. Online Sync: Run parallel syncs for PostgreSQL (logical replication), Object Storage (mc mirror), and ClickHouse (remote() loop).
    3. Freeze & Final Delta: Scale v1 web and worker to 0. Perform final deltas for Postgres, Object Storage, and ClickHouse.
    4. Traffic Shift: Delete the v1 Ingress and create/enable the v2 Ingress, or retarget your external LoadBalancer/Ingress to the v2 service.
  3. Migrate Langfuse Helm Chart from v1.x to v2.0

    main

    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.

    Migration Strategies

    1. In-place Upgrade (All stores external): Use this if your PostgreSQL and ClickHouse instances are managed externally to the Helm chart. This is the simplest path as it only involves updating the application configuration.
    2. Sibling + Traffic Shift (Bundled stores): Use this if you are using the bundled stores provided by the chart. This method involves deploying a 'sibling' installation (a new version alongside the old one) and then shifting traffic to the new version to minimize downtime.

    Automated Migration Tools

    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.

    Requirements

    To run the automated migration, you must have the following installed:

    • kubectl
    • helm >= 3.17
    • jq
    • python3
    • A YAML parser: yq (mikefarah version), PyYAML, or Ruby.

    Example Files for Reference

    • 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).
  4. Install Langfuse v4 via Helm

    main

    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:

    • ClickHouse: 25.12 minimum, 26.4 recommended
    • Postgres: 16 recommended
    • Redis: 7.2 recommended
    # Refer to examples/minimal-installation/ for specific commands
  5. Install Prerequisites for Langfuse (cert-manager and ClickHouse operator)

    main

    Before 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:

    1. cert-manager: Required for certificate management.
    2. ClickHouse operator: Required for managing ClickHouse clusters.

    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=120s
  6. Migrate Langfuse Helm Chart from v0.13 to v1.0

    main

    When 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.

    Required Migration Steps:

    1. Restructure Core Config: Move global settings (resources, affinity, nodeSelector, etc.) under the langfuse key.
    2. Update Image Config: Use the new langfuse.image structure. You can now override images per component (web or worker).
    3. Update Secrets:
      • For salt, use langfuse.salt.value or langfuse.salt.secretKeyRef.
      • For encryptionKey, use langfuse.encryptionKey.value or langfuse.encryptionKey.existingSecret / existingSecretKey.
    4. Migrate Integrated Services:
      • Redis: Move from valkey or additionalEnv to the redis section. Use nameOverride: valkey to keep the old name.
      • Clickhouse: Move from clickhouse or additionalEnv to the clickhouse section. Warning: clickhouse configuration and langfuse.additionalEnv ClickHouse variables are mutually exclusive.
      • S3/MinIO: Move from minio or additionalEnv to the s3 section. Use nameOverride: minio to keep the old name.
    5. Update Feature Flags: Move flags to 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>
  7. Use external data stores with Langfuse Helm chart

    main

    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.yaml
  8. Manual Step: Object Storage Sync (MinIO to SeaweedFS)

    main

    Use the MinIO Client (mc) to mirror data from the v1 MinIO instance to the v2 SeaweedFS instance.

    Sync Process:

    1. Set up aliases for both v1 and v2.
    2. Create the target bucket.
    3. Run 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/langfuse
    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"
    mc mb --ignore-existing v2/langfuse
    mc mirror --overwrite --watch v1/langfuse v2/langfuse
  9. Upgrade Path: All Stores External

    main

    If 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.yaml
  10. Automated Migration Script for v1 to v2 Upgrade

    main

    The 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.yaml

    Run without interactive prompts:

    ./migrate-v1-to-v2.sh --values /path/to/your-v1-values.yaml --yes

    Perform a dry run (preflight + generate values only):

    ./migrate-v1-to-v2.sh --values /path/to/your-v1-values.yaml --dry-run
    cd examples/upgrade-v1-to-v2/scripts
    ./migrate-v1-to-v2.sh --values /path/to/your-v1-values.yaml
  11. Manual Step: PostgreSQL Logical Replication Setup

    main

    To 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 = 10

    2. 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.