Self-hosting Langfuse on-premise means running its open-source Docker or Kubernetes deployment inside a private network so trace data, prompts and model outputs never leave company infrastructure. The minimal self-hosted stack requires a Postgres database for metadata, a ClickHouse instance for trace analytics, Redis for caching and queueing, and object storage such as S3-compatible MinIO for large payloads, all of which can be deployed with the official Langfuse Helm chart or a docker-compose file for smaller teams. Production deployments should run Langfuse behind a reverse proxy with TLS, size ClickHouse storage for expected trace volume since verbose traces from RAG or agent pipelines grow quickly, and set retention policies to control disk growth. Instrumenting an application typically takes a few lines of SDK code in Python or TypeScript, or automatic tracing through OpenTelemetry, LangChain or LlamaIndex integrations that Langfuse ships out of the box. Access control, single sign-on and role-based permissions are available on the self-hosted enterprise edition for teams that need to restrict who can view prompts containing sensitive data. Nanobase AI deploys self-hosted Langfuse on client-owned Kubernetes clusters as part of on-premise LLM stacks, keeping every prompt and trace inside the customer's own network boundary.
Decide traffic tier and retention before touching infrastructure
The most common mistake in a self-hosted Langfuse rollout is provisioning storage for launch traffic instead of the traffic six months later, once agentic and RAG pipelines start generating dozens of spans per request. Sizing decisions made before deployment save far more engineering time than fixes made after ClickHouse disks are already full, since resizing a production analytics database under load is much harder than provisioning it correctly the first time.
Sizing guide by expected trace volume
| Traffic tier | Approx. daily traces | Postgres | ClickHouse | Redis | Object storage |
|---|---|---|---|---|---|
| Pilot | Up to about 10,000/day | Single small instance | Single node, tens of GB | Single instance, minimal memory | Tens of GB, optional at this scale |
| Team | About 10,000-200,000/day | Replicated instance, tens of GB | Single beefy node or small cluster, hundreds of GB, monitor weekly growth | Small cluster or managed Redis | Hundreds of GB with lifecycle rules to expire old payloads |
| Enterprise | 200,000+/day across teams | HA Postgres cluster | Multi-node cluster, terabyte scale with tiered or cold storage | Redis cluster with persistence enabled | Multi-terabyte with defined retention windows |
Trace volume, not raw user count, drives ClickHouse and object-storage sizing, because a single multi-step agent request can generate dozens of spans while a simple chatbot call generates one.
A numbered deployment checklist
- Provision Postgres, ClickHouse, Redis and S3-compatible storage, or use the docker-compose bundle for a pilot.
- Deploy Langfuse via the Helm chart on Kubernetes, or docker-compose for a single node, pointing it at provisioned services rather than bundled defaults beyond a pilot.
- Place Langfuse behind a reverse proxy with TLS and internal-only DNS if traces must never leave the network.
- Set retention policies on ClickHouse and object storage before production traffic starts, not after disks approach capacity.
- Instrument applications with the Langfuse SDK, or OpenTelemetry, LangChain or LlamaIndex integrations, and verify traces arrive before removing temporary logging.
- Enable single sign-on and role-based access on the enterprise edition if traces will contain regulated prompts.
Skipping the reverse proxy or the retention step is how a pilot quietly becomes an ungoverned production system. A minimal pilot can run within an afternoon using the project's own quick-start path:
git clone https://github.com/langfuse/langfuse.git
cd langfuse && docker compose up -dWhat breaks first when sizing is wrong
The most common failure is silent backpressure: ClickHouse disk usage climbs unnoticed until ingestion queues, and traces arrive late or get dropped under sustained load. A disk-usage alert set well before capacity is reached is the single cheapest safeguard in this deployment, turning a silent failure into scheduled maintenance instead of an incident.
Networking and access considerations for a locked-down environment
Fully air-gapped deployments need container images mirrored into an internal registry ahead of time, since the Helm chart and docker-compose file both assume outbound access on first run. Internal certificate authorities must be trusted by the Langfuse services and any client SDKs, and default outbound telemetry from some components should be disabled under a strict no-egress policy. Air-gapping is a checklist of defaults to override, not a single switch, and a missed one usually surfaces as a silent startup failure. This overlaps with a broader on-premise LLM deployment; teams still deciding on the right layer should see Langfuse versus LangSmith versus Arize Phoenix.
Frequently asked questions
Can Langfuse run fully air-gapped with no outbound internet access?
Yes, once container images are mirrored into an internal registry and any default outbound telemetry is disabled in configuration. The core tracing, dashboard and evaluation functionality does not require external connectivity once Postgres, ClickHouse, Redis and object storage are all running inside the same private network.
How much disk space should we budget for ClickHouse in a mid-size deployment?
Budget in the low hundreds of gigabytes for a team-tier deployment handling tens to low hundreds of thousands of traces daily, and monitor growth weekly rather than setting a number once. Verbose traces from RAG or agentic pipelines grow storage faster than simple chatbot traces.
Do we need Kubernetes, or is docker-compose enough for production?
Docker-compose is workable for a pilot or small team-tier deployment on a single well-resourced host, but production deployments handling meaningful traffic typically move to the Helm chart on Kubernetes for high availability, rolling updates and easier scaling of the ClickHouse and ingestion layers.
What happens to existing traces if we need to migrate to a bigger ClickHouse cluster later?
Existing data can be migrated using standard ClickHouse replication or export-and-reload procedures, since Langfuse stores analytics data in ClickHouse's own table format rather than a proprietary one. Planning the migration path during initial sizing, rather than after the cluster is full, makes this routine maintenance instead of an emergency.
How Nanobase AI helps
We deploy self-hosted Langfuse on client-owned Kubernetes clusters as part of broader on-premise LLM stacks, sizing Postgres, ClickHouse, Redis and object storage against projected trace volume rather than default values. Our team handles the air-gapped registry mirroring, certificate trust and retention policy work needed to keep every prompt and trace inside the customer's own network. See our solutions or reach out with your expected traffic profile for a sizing recommendation.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.