Self-Host Langfuse on Kubernetes

Langfuse traces LLM calls, manages prompts, runs evaluations, and stores datasets. Self-hosting it is more involved than most tools of its size, because it needs four backing services rather than one. This page covers what those are, why each exists, and what to budget. Edka wires them from services already running on your cluster, in your own cloud account.

What Langfuse Needs to Run

Langfuse separates its storage by access pattern, which is what makes tracing stay fast at volume:

  • PostgreSQL for application metadata: projects, users, prompts, API keys. Small and transactional.
  • ClickHouse for traces and observations. This is the high-volume path. A single LLM request can produce dozens of spans, and a column store answers aggregate queries over them without scanning every field.
  • Valkey as the queue and cache between the web and worker deployments. Ingestion is buffered here so a burst of traces does not block the API.
  • S3-compatible object storage for event uploads, batch exports, and media.

You cannot collapse these into one database. If you want a tracing tool with a single dependency, Langfuse is not it. What you get in exchange is ingestion that keeps up with production traffic.

Edka points Langfuse at existing PostgreSQL, ClickHouse, and Valkey installations on your cluster and an S3-compatible storage integration, rather than running another copy of each.

Resource Requirements

DeploymentReplicasCPU requestMemory requestCPU limitMemory limit
Web1250m1Gi1000m2Gi
Worker1250m1Gi1000m2Gi

Both are Node.js processes, running with --max-old-space-size=1536 by default so the heap stays inside the 2Gi limit.

At defaults Langfuse itself requests 500m CPU and 2Gi memory. The four backing services need considerably more, and ClickHouse is the heaviest. Plan the cluster around those rather than around Langfuse. See the Hetzner instance types table.

Scale the worker first when ingestion lags, and the web deployment when the UI or API feels slow. They scale independently.

What Edka Provisions

  • Langfuse web and worker. Separate deployments for the UI/API and background jobs, with independent replica and resource settings.
  • PostgreSQL metadata store. An existing PostgreSQL installation, database, and user for application data.
  • ClickHouse event store. An existing ClickHouse installation and a dedicated database for traces and events.
  • Valkey queue and cache. An existing Valkey installation.
  • S3-compatible object storage. An organization object storage integration for event upload, batch export, and media.
  • Gateway access. Optionally expose the UI and API through a cluster traffic class and hostname.

Configuration Options

  • Datastores. Choose the PostgreSQL, ClickHouse, and Valkey instances. Edka resolves credentials from Kubernetes Secrets and projects them into the Langfuse runtime secret.
  • Object storage. Choose an S3-compatible integration for event, export, and media buckets.
  • Security. Edka generates a stable salt, session secret, and 64 character hexadecimal encryption key. You can supply an optional Enterprise licence key.
  • Authentication. Disable public signups, disable username and password auth, or keep the default first-run setup flow.
  • Resources. Web and worker replicas, CPU and memory requests, memory limits, and Node.js runtime options.
  • Auto-updates. Let the Edka agent apply newer chart and image versions using a patch, minor, major, or custom policy.

Agent Tracing

Hermes Agent can send traces to an installed Langfuse instance. Enable tracing in the Hermes configuration, select the Langfuse instance in the same cluster, and provide the project public and secret keys. Edka fills the in-cluster base URL from the selected instance, so Hermes reaches Langfuse over the cluster service rather than a public route.

Deploy Langfuse

  1. Click “Deploy Langfuse” below.
  2. Select existing PostgreSQL, ClickHouse, and Valkey instances.
  3. Select an S3-compatible object storage integration.
  4. Choose whether to expose Langfuse through a Gateway traffic class.
  5. Deploy, open Langfuse, create a project, and copy the project keys into your agent or application configuration.

Deploy Langfuse
icon related to Langfuse

Langfuse

Observability

Free

Category

LLM Observability

Run Langfuse on your own Kubernetes cluster with PostgreSQL, ClickHouse, Valkey, and S3 storage. Dependencies, resource defaults, and setup explained.

Get started