The best ways to host Langfuse in 2026

Langfuse is one of the few LLM observability tools that's genuinely pleasant to self-host, which is why so many teams try. Then they discover it isn't one service — it's a web app plus Postgres plus ClickHouse plus Redis plus blob storage, and the interesting hosting decision is about those four dependencies rather than the app itself.

This is a comparison of the realistic places to put it, what each one costs you in operational attention, and the case for not self-hosting at all. I build a compute platform, so I have a horse in this race; I've tried to be useful rather than promotional, and I'll say plainly where we're a bad fit.

What Langfuse actually needs

Before comparing hosts, be clear about the shape of the thing. Recent Langfuse versions split into a web container and a worker container, backed by:

• Postgres — transactional data: users, projects, API keys, prompts, configuration. Small, but the one you truly cannot lose.
• ClickHouse — traces, observations, scores. This is where the volume is, and it grows with your LLM traffic rather than your user count.
• Redis or a compatible cache — queueing between web and worker, plus caching.
• Blob storage — S3-compatible, for large event payloads and exports.

So "hosting Langfuse" means hosting a stateless-ish app plus one small critical database, one analytical database, a cache, and object storage. Any option that hides that from you is making a trade you should understand.

The realistic options

1. Langfuse Cloud

Worth stating first because a lot of self-hosting is done reflexively. If your objection to managed observability isn't a hard data-residency or compliance requirement, the maintainers running it will almost certainly do it better and cheaper than you will once you price in your own time on ClickHouse upgrades.

Self-host when you have a real reason: traces contain data that can't leave your infrastructure, you're air-gapped, you need to keep years of traces at a volume that makes per-seat or per-event pricing painful, or you want to query the trace store directly for your own analytics. Those are all legitimate. "We prefer to self-host" as a default is how teams acquire a ClickHouse cluster they don't want.

2. One VM, Docker Compose

The pragmatic starting point, and it goes further than people expect. Langfuse publishes a compose file that stands up every dependency. On one reasonably sized machine this handles a lot of trace volume.

What you're accepting: everything is on one host, so the host is your availability story and your backup story. It's fine for internal tooling where an hour of downtime is an annoyance. It's not fine when traces are feeding a customer-facing feature or a compliance record.

If you take this route, the single highest-value thing you can do is get your Postgres backups off that machine and test a restore. The ClickHouse data is regrettable to lose; the Postgres data is unrecoverable — it's your projects, keys, and prompt history.

3. App on a PaaS, dependencies managed separately

The setup most production deployments converge on. Run the web and worker containers on whatever platform you already use, and point them at a managed Postgres, a managed ClickHouse, managed Redis, and S3-compatible storage.

This is more expensive in dollars and much cheaper in attention. Each dependency gets someone else's backups, patching, and failover. The app containers become genuinely disposable, which means deploys and scaling stop being frightening.

The main watch-out is network topology and egress. Four managed services in four places, each charging for data leaving it, with an analytical database in the middle, adds up quietly. Keep them in one region and one provider where you can.

4. Kubernetes with the Helm chart

There's an official chart, and it's the right answer if you already run Kubernetes and have opinions about operators for stateful services. It's the wrong answer if adopting Kubernetes is something you'd be doing *for* Langfuse. Running ClickHouse well on Kubernetes is a specialization, not a side quest.

5. MicroVM platforms (where we fit, and don't)

Since I build one, let me be precise about the fit. A platform like ours deploys the Langfuse containers from git, gives them a URL, and runs managed Postgres next to them, with each app in a hardware-isolated microVM. That covers the app tier and the Postgres dependency comfortably.

What it does not currently cover is a managed ClickHouse. So a full Langfuse deployment here means bringing your own ClickHouse — cloud-managed, or self-run — and pointing the app at it. If you want a single platform that hands you every Langfuse dependency managed, we aren't it today, and I'd rather say so than let you find out mid-deploy.

Where this genuinely shines is the adjacent problem: you're already running agents whose code executes in sandboxes, and you want the observability stack near the workloads it's watching, on infrastructure that costs nothing when idle. An internal Langfuse instance that sleeps overnight and wakes in about a second when someone opens a dashboard is a real cost difference versus a permanently-running deployment.

Sizing, honestly

Two numbers determine everything and neither is your user count.

Trace volume drives ClickHouse. Every LLM call you instrument becomes observations with full inputs and outputs, and prompt payloads are not small. A chatty agent produces far more observability data than a chat app with the same number of users, because one user request can be dozens of model calls.

Retention drives storage. The default instinct is to keep everything forever; the useful question is how far back anyone has actually looked. Most teams debug within days and analyze aggregates over months. Setting a retention policy early is much easier than reclaiming space later.

# Before choosing a host, get your own numbers. Rough shape:
#   observations/day x average payload size = ClickHouse growth/day
#
# Run against your existing instance to size the next one.
clickhouse-client --query "
  SELECT
    toDate(start_time) AS day,
    count() AS observations,
    formatReadableSize(sum(length(input) + length(output))) AS payload
  FROM observations
  WHERE start_time > now() - INTERVAL 14 DAY
  GROUP BY day ORDER BY day DESC"

Choosing

• Evaluating Langfuse, or your traces aren't sensitive: use their cloud. Revisit if cost or residency becomes a real constraint.
• Internal tooling, modest volume, one team: one VM with Docker Compose, Postgres backed up off-box.
• Production, traces you depend on: app containers on a PaaS, every dependency managed. Most expensive, least surprising.
• Already on Kubernetes with stateful experience: the Helm chart.
• Want it near your agent workloads with zero idle cost, and can bring your own ClickHouse: a microVM platform for the app and Postgres tiers.

The short version

Langfuse hosting is a stateful-dependency question wearing an app-hosting costume. The web and worker containers will run anywhere; ClickHouse determines whether your deployment is pleasant or a second job.

Decide who operates ClickHouse before you decide where the app goes. Everything else follows from that, and "not us" is a perfectly good answer — including choosing their cloud and spending the saved time on the product you're actually building.