Here's a quick reality check. I went through the actual production docs for Langfuse, Arize Phoenix, and Laminar, three popular open-source agent observability tools. Deployment is fast. Ownership isn't free. Here's what that actually means for your team.

The setup is not the hard part

docker compose up -d. A minute later, there's a UI and a trace. All three tools get you there in under fifteen minutes. That's the demo. It's real, and it's genuinely good.

But "it's open source, just self-host it" answers the wrong question. Nobody was asking "can I get this running." The real question is "can I run this reliably for as long as my product exists." Every one of these projects' own docs admits the gap between those two, once you read past the quickstart.

So what? Getting it running is easy. Keeping it running is the actual job, and it's the part nobody prices in.

What you're actually signing up to operate

Here's what each project's own docs say you need once you're past the quickstart, tool by tool. One term to define up front: HA means high availability, running enough redundant replicas that one node failing doesn't take the whole system down. Where a row below says "no failover," a crash means downtime until someone steps in.

Phoenix is genuinely the lightest of the three, and a single container on SQLite is a fine way to run it solo. But once you move beyond a solo/dev setup, the architecture gets materially heavier: a production database, durable storage, redundancy, backups, monitoring, and for Langfuse and Laminar, additional queue/cache infrastructure. You're no longer just running an app. You're operating its data infrastructure too.

Where the hidden cost actually comes from

Four buckets. Conflating them is how "it's open source, it's free" survives as a sentence people say out loud.

1. Infrastructure. ClickHouse is, in Langfuse's own words, "CPU and memory intensive." Their Helm guidance starts each replica at 2 CPU cores and 8-16Gi of memory, minimum three replicas for HA, and replica count can't change at runtime without downtime. That's a floor of roughly 6 cores and 24-48Gi before you store one trace. Add Postgres, Redis, and object storage that grows on every ingestion event, and the bill is real, not a rounding error.

2. Query compute. Ingestion and querying fight for the same cluster. Traces are being written while engineers run dashboards, evals, and ad-hoc SQL on historical data. Size for the combined peak, not just write volume, or a heavy query slows down ingestion for everyone. This is why Langfuse points people toward ClickHouse Cloud or BYOC at scale: managed offerings separate query compute from ingestion compute. A basic self-managed deployment doesn't give you that separation by default. Getting it means more architecture and more operational complexity.

3. Engineering time. Someone needs to know ClickHouse well enough to write correct grants and read a query plan. Someone owns Postgres backups, tested, not just scheduled. Someone owns the Redis failure mode where the wrong eviction policy silently kills queue processing while the worker looks healthy. None of this is one-time. Major version upgrades need a paused-ingestion, copy-then-cutover sequence, because the ClickHouse schema isn't a stable contract across releases.

4. Operational risk. All three projects document a managed off-ramp once you're past a certain scale. Langfuse points to ClickHouse Cloud or BYOC. Phoenix's high-volume path is Arize's own managed OLAP. Laminar's team will directly run your "self-hosted" deployment inside your own cloud account. None of them say "don't self-host at scale" outright. But three independent projects building the same off-ramp is a pattern, and it tells you where their own engineers see the ceiling. On the OSS tier, support is the community Discord or GitHub. If it's down, that's the support contract you signed.

"Ten hours a month to keep this healthy" isn't just ten hours at loaded cost. It's what didn't get built during those ten hours. For a five-person team, that's usually the bigger number, and it's the one that never shows up on an invoice.

The numbers, worked through

I'll model this on Langfuse specifically. Its production requirements are the most explicitly documented of the three, and the math would need re-deriving for Phoenix or Laminar's own architecture anyway.

There isn't one "self-hosting cost." A single-node deployment and a production deployment with high availability are very different things. I'll show both, so you can decide which one actually matches your requirements.

The scenario: a ten-person agent startup doing 10 million traces a month. Assume roughly five ingestion events per trace, which puts average throughput around 1,150 events a minute, several times that at peak.

Why 10 million and not some other number? It's not a documented threshold from any of the three vendors, it's a deliberately round, plausible mid-size volume for an agent product with real usage, picked to make the HA/production tier concrete rather than theoretical. If your own numbers are smaller, the second scenario further down reruns this same math at 500k traces a month.

That's under 20 events a second. Nothing for a single node. So why does a three-replica ClickHouse cluster show up as the production target? Because that's the HA topology Langfuse's docs specify, not a throughput requirement. A single node has no failover. At this volume, you're paying for reliability, not capacity.

Day 1: an engineer with an AI coding assistant gets Langfuse running via Compose in under an hour. The docs call this a testing configuration: no HA, single node.

Production build: HA ClickHouse, managed or self-hosted Postgres, correctly configured Redis, S3 with lifecycle policies, monitoring, a tested backup and restore process.

Eventually: a major version upgrade lands. Rarely a routine bump, per the schema-stability point above.

Here's how I got these numbers, so you can check my work instead of taking my word for it.

Infrastructure pricing. I use AWS on-demand rates, checked in September 2026. Linking straight to the specific instances.vantage.sh instance page for each figure below, so the number is checkable, not just AWS's general pricing page, which renders its tables in a way my tools couldn't read cleanly.

For ClickHouse, I model an r6i.large at $0.126/hr (2 vCPU / 16 GiB), or ~$92/month, which sits at the upper end of Langfuse's documented starting guidance of 2 CPU cores and 8-16 GiB memory per replica.

For Postgres, I use a db.m6g.large at $0.159/hr single-AZ, or ~$116/month, and roughly twice that for Multi-AZ since AWS bills the synchronous standby as a second instance. For Redis, I use a cache.t4g.small at $0.032/hr, or ~$23/month.

Storage uses AWS gp3 pricing at $0.08/GB-month. For S3 I use $0.023/GB-month. That's the one price in this model I didn't independently re-verify against a live AWS table this round, so treat it as the softest figure below.

On top of that pricing sit sizing assumptions that are mine, not a vendor's. For storage modeling only, I assume 50KB per trace and 30-day retention. This is my modeling assumption, not a vendor benchmark. Actual trace size varies widely depending on span count, prompts, completions, tool calls, metadata, and other captured payloads. For the replication factor: Langfuse's HA topology uses ClickHouse's ReplicatedMergeTree, where each replica holds a complete copy of the data for failover, so I model HA storage at three full copies, not some fraction of that. Move any of these assumptions and the dollar figures move with them.

The ClickHouse ranges below combine the EC2 instance cost with the modeled gp3 storage required for each trace-volume scenario.

Single node (no HA) versus HA (3 ClickHouse replicas):

• ClickHouse: ~$120-160/mo vs. ~$360-440/mo

• Postgres: ~$110-140/mo vs. ~$230-260/mo (Multi-AZ standby)

• Redis / Valkey: ~$20-30/mo vs. ~$40-60/mo

• Object storage: ~$20-40/mo vs. ~$30-60/mo (softest number, see above)

• App compute: ~$40-60/mo vs. ~$100-150/mo

• Infra subtotal: ~$310-430/mo vs. ~$760-970/mo

That HA subtotal is lower than what I'd have guessed without pricing it out. This is what one AWS configuration close to the documented starting requirements costs at current on-demand rates. Plenty of teams run bigger instances than the documented floor for headroom, in which case your real number goes up from here, not down. Excluded entirely: ClickHouse Keeper/Zookeeper coordination nodes if you're not using the built-in keeper mode, data transfer/egress, and multi-region replicas.

The infrastructure numbers above come from documented requirements and cloud pricing. The engineering hours below are different: they're my estimates based on the work involved. Use your own numbers if your team already operates this stack. These specific ones assume an engineer with general infrastructure experience, not a dedicated ClickHouse operator.

1. Initial setup, single node (no HA): 25-40 hrs. Getting past the testing-only Compose config to one durable node with real, tested backups: the specific gap Langfuse's own docs describe between the quickstart and a production deployment.

2. Initial setup, HA (3 ClickHouse replicas): 60-100 hrs. The above plus three-replica ClickHouse at the documented topology, HA Postgres, correctly configured Redis, S3 lifecycle policies, monitoring, a tested restore, and the network hardening Phoenix's own docs describe for its SSRF surface.

3. Monthly maintenance, single node (no HA): 3-6 hrs. Patching, watching storage growth, occasional troubleshooting.

4. Monthly maintenance, HA (3 ClickHouse replicas): 8-14 hrs. The above plus replica health, queue monitoring, capacity review.

An engineer who already runs ClickHouse could halve these. A first-timer could blow past them. The exact number isn't the point. The point is that it's not zero, and the maintenance hours come back every month.

For the example below, I use a $130/hr fully loaded engineering cost. That's an illustrative assumption, not a benchmark. The raw hours above are there so you can substitute your team's actual cost.

Year 1 TCO (infrastructure + initial setup + 12 months of maintenance): $11,600-19,700 for a single node, $29,400-46,500 for HA.

Ongoing annual TCO, Year 2 onward (infrastructure + 12 months of maintenance, no setup cost): $8,400-14,500 for a single node, $21,600-33,500 for HA.

So what? That's the number "it's open source" leaves out. And it's not the final number either. The real question is whether $21,600 to $33,500 a year in ongoing cost, plus a real Year 1 setup cost on top, is actually cheaper than a managed option like Rius that folds all of this infrastructure into one bill. That's the build-versus-buy call, and only you have the inputs to make it.

A second scenario: 500k traces a month

Same math, a much earlier-stage team: 500,000 traces a month instead of 10 million, 1/20th the volume above.

Infrastructure barely moves. If you want the three-replica HA topology documented by Langfuse, the baseline topology doesn't change just because you're doing 500k rather than 10 million traces. Only the pieces that scale with data volume, storage mostly, actually shrink.

• ClickHouse: ~$95-100/mo vs. ~$280-290/mo

• Postgres: ~$110-140/mo vs. ~$230-260/mo (unchanged, not volume-driven)

• Redis / Valkey: ~$20-30/mo vs. ~$40-60/mo (unchanged)

• Object storage: ~$10-20/mo vs. ~$15-30/mo

• App compute: ~$40-60/mo vs. ~$100-150/mo (unchanged)

• Infra subtotal: ~$275-350/mo vs. ~$665-790/mo

Hours barely move either. Setup is the same work regardless of trace volume; you're still standing up the same components. Maintenance trends toward the low end of the range from the first scenario, less data and fewer concurrent queries to keep an eye on, but it doesn't hit zero: patching and replica health checks happen whether you're doing 500k traces or 10 million.

Year 1 TCO: $11,230-15,640 for a single node, $28,260-38,080 for HA.

Ongoing annual TCO, Year 2 onward: $7,980-10,440 for a single node, $20,460-25,080 for HA.

Compared against the 10-million-trace scenario's ongoing annual TCO, $8,400-14,500 for a single node and $21,600-33,500 for HA, the HA floor barely moves even though volume dropped 20x.

So what? Trace volume dropped 20x, but the baseline cost of the HA topology didn't drop anywhere close to 20x. That's "reliability, not capacity" made concrete. If you need failover, much of that infrastructure and operational floor exists at both volumes. If you don't need HA yet, staying on a single node is the much bigger cost lever.

20x more traces. A much smaller change in the HA infrastructure floor.

Illustrative AWS infrastructure model based on the assumptions above. At these volumes, HA is primarily a reliability cost, not an ingestion-capacity cost.

But doesn't AI make this cheap now?

Fair question, so let's answer it directly instead of dodging it. An engineer with Claude Code or a similar tool can generate a working Compose file, wire up env vars from the docs, and get to "the UI loads and a trace shows up" faster than reading the docs by hand. That's real. It's not the whole story, but it's real.

It's not just setup, either. AI genuinely helps with the ongoing work: investigating an incident, drafting an upgrade script, analyzing a slow ClickHouse query, writing Terraform. No argument there.

What it doesn't do is take the responsibility off your plate. It can help you figure out why a worker silently stopped consuming its queue, but it isn't the one paged at 2am, and it doesn't own the call if it's wrong. It can draft a network policy against SSRF, but someone still has to verify it actually closes the hole on your specific cloud provider's metadata endpoint. Capacity planning against your real traffic, running an actual DR drill, deciding when an upgrade is safe to schedule: these don't resist AI because they're hard to explain. They resist it because they need someone accountable, in the loop, with the authority to act.

How much does AI reduce that cost? It depends heavily on the engineer and the stack. I don't think there's an honest percentage I can put on it. It clearly reduces setup and troubleshooting time. What it doesn't reduce is the infrastructure bill, and it doesn't remove the need for someone to own capacity planning, upgrades, recovery, and incidents.

AI compresses the work. It doesn't transfer the responsibility. Setting up ClickHouse well is one thing, and an assistant genuinely helps there. Owning it when it breaks at scale is a different thing, and that role doesn't go away just because the first one got faster.

When self-hosting actually makes sense

None of this means self-hosting is wrong. It means "it's open source" isn't a full argument for it. Before you decide, run through this:

1. Do you already have someone who can operate ClickHouse, or are you building that skill from zero?

2. Do you actually need high availability, and if so, have you priced the production topology your chosen tool documents?

3. Do you have a backup process you've actually tested by restoring from it?

4. Have you budgeted the ongoing engineering time and what it costs you in opportunity, not just the cloud bill?

5. Is there a real compliance reason ruling out a managed option, or is self-hosting just the default because nobody asked?

6. When it breaks, who's actually paged, and are they equipped for a ClickHouse or Redis incident specifically?

If you can answer all six with confidence, self-host with confidence. These are three solid pieces of software, and self-hosting one of them can be the right call: you have the team, the compliance reason, the scale economics, or the customization need. If you can't answer them yet, that's worth knowing before you're three months into a Kubernetes migration you didn't fully scope.

So should you self-host?

Make the self-hosting decision because you want control, data residency, or economics that work at your scale. Not because the Compose file took ten minutes to start.

Deployment is free. Ownership isn't.

Frequently Asked Questions

How much does it cost to self-host Langfuse?

Depends entirely on whether you need high availability. For a single node with no failover, expect around $11,600-$19,700 in year one (infrastructure, setup, and maintenance) and $8,400-$14,500 a year after that. For the HA topology Langfuse documents, three ClickHouse replicas, it's $29,400-$46,500 in year one and $21,600-$33,500 ongoing. Those figures model a 10-million-trace-a-month team at a $130/hr fully loaded engineering rate, the raw hours are further up if you want to substitute your own, and a lower-volume team doesn't save nearly as much on the HA number as you'd expect.

Is ClickHouse required to self-host Langfuse or Laminar?

Yes, for both. It's the trace/analytics store, and neither project's docs treat it as optional at production scale. Arize Phoenix is the exception: it runs on Postgres for production and only moves to managed OLAP at high volume.

Do you need high availability to self-host an observability tool?

No. High Availability (HA) is a reliability decision, not a volume requirement. The documented three-replica ClickHouse topology costs roughly the same whether you're doing 500k traces a month or 10 million. If you don't strictly need failover, staying on a single node is the bigger lever for keeping costs down, not your trace volume.

How much does AI reduce the cost of self-hosting?

Less than the "it's all automated now" version implies. It clearly speeds up setup and troubleshooting. It doesn't touch the infrastructure bill, and it doesn't remove the need for someone to own capacity planning, upgrades, recovery, and incidents.