A Langfuse Alternative With No Server: When a File Beats a Deployment

Most “alternative to X” pages are written by whoever wants you to switch. This one starts with the case for staying.

When you should use Langfuse

If you want traces across a multi-step agent, a dashboard your team can look at, evaluation runs against datasets, prompt versioning, or a UI where a non-engineer can see what happened, use Langfuse or a platform like it. Those features are real, they are mature, and a file does not have them. Nothing below is an argument that it does.

The generous version of the comparison is the only one worth writing, because the ungenerous one gets corrected in the comments by someone who has used both.

When the deployment is the problem

Self-hosting Langfuse is a multi-service Docker Compose deployment. The Langfuse documentation recommends at least 4 cores and 16 GiB of memory, with 100 GiB of storage for a VM, and states plainly that the Compose setup lacks high availability, scaling and backup.

That is a reasonable ask for a team running an AI product. It is an unreasonable ask if you are one person who wants to know what your coding agent did this afternoon.

There is also a category of user for whom the hosted tier is not an option at all, because the data cannot leave the building. Self-hosting solves that and hands you the operations bill instead.

The alternative, stated honestly

A hook that appends to a local file.

pip install homestead-memory     # needs Python 3.10+
hsm hook --install               # prints a snippet; it does not edit your settings
hsm watch                        # what your agent actually did

No account, no server, no container, no database. The output is a JSONL file on your disk that you can open in any editor.

	Langfuse self-hosted	This
Tracing, dashboards, evals	Yes	No
Prompt management, team UI	Yes	No
Infrastructure to run	Multi-service deployment	None
Setup	Compose stack and its dependencies	One pip install and one snippet
Data leaves the machine	No	No
Record resists editing	No	Yes, hash-chained and signable
Harness support	Broad, via SDKs	Claude Code only

The one thing a platform does not give you

Observability tools are built to answer “how is it performing”. They are not built to answer “can I prove this record was not changed”. Their storage is a normal database, and a row in a normal database can be updated.

Each record here carries the hash of the record before it. An edit, a deletion or a reorder breaks every hash after it, and the break is reported at the exact index. Signing the head with hsm checkpoint catches the remaining case, where someone rebuilds the whole chain and recomputes every hash.

This is tamper-evident, not tamper-proof. It does not prevent an edit. It makes one detectable, which is a smaller claim and the only one the mechanism supports.

hsm export --evidence produces a pack that a third party verifies with the Python standard library alone. They need nothing installed, and nothing from us.

Where this loses, again, in a list

• No dashboards, no evaluation runs, no team UI.
• Capture is Claude Code only. Cursor and Codex need different mechanisms and are not built.
• About 124ms per tool call, measured, median across both hook phases.
• It records what the harness reported. If a tool lies, you get a hash-chained lie.
• The signing key lives on the same machine as the log, so publishing a checkpoint elsewhere is what closes that gap.

If you read that list and the trade still looks right for your case, it takes about a minute:

github.com/fuckbigtech-ai/homestead-memory