Can I run Rius alongside Langfuse while I migrate?
Yes, Rius runs alongside Langfuse during a migration, and both backends can receive the same traces. Add Rius as a second exporter in your OpenTelemetry Collector, compare the two on real traffic, and cut over when Rius shows what you need. Nothing in the Migrate to Rius path requires a hard switch, and you can reverse it until you revoke your Langfuse keys.
How it works
Langfuse and Rius both work with OpenTelemetry traces, so the same spans can go to both. The simplest way to do that is a Collector with two exporters in one traces pipeline.
- The Collector receives spans from your application once and sends a copy to each exporter. Both backends see identical spans.
- Use the
otlphttpexporter for Rius. The plainotlpexporter speaks gRPC, which the Rius endpoint does not accept. - Rius authenticates with a single API key sent as a Bearer token. Langfuse’s OTLP endpoint uses Basic auth built from its public and secret keys, so each exporter keeps its own header.
- The Collector forwards spans unchanged. Your instrumentation stays as it is, and Rius reads the OpenTelemetry GenAI attributes as well as OpenInference and OpenLLMetry attributes, so models, tokens and cost appear without code changes.
If you instrument with the Langfuse SDK itself, you cannot point it at Rius, because its exporter and auth are Langfuse’s own. In that case, swap to the Rius SDK in one service while the other services keep reporting to Langfuse. If you use the Rius SDK next to Langfuse’s tracer provider, setting RIUS_BRIDGE_FOREIGN_PROVIDER to true also sends the spans of that other global tracer provider to Rius.
The Collector page covers the exporter details.
Set it up
- Create a Rius workspace and an API key. Keys start with
ri_. Store the key in an environment variable named RIUS_API_KEY so it stays out of the config file. - Add Rius as a second exporter next to your existing Langfuse exporter, and list both in the traces pipeline:
exporters:
otlphttp/langfuse:
endpoint: https://cloud.langfuse.com/api/public/otel
headers:
authorization: Basic ${env:LANGFUSE_BASIC_AUTH}
otlphttp/rius:
endpoint: https://ingest.eu.console.rius-glassflow.com
encoding: proto
compression: gzip
headers:
authorization: Bearer ${env:RIUS_API_KEY}
service:
pipelines:
traces:
receivers: [otlp]
processors: [batch]
exporters: [otlphttp/langfuse, otlphttp/rius]- Give the exporter the base URL,
https://ingest.eu.console.rius-glassflow.com. Theotlphttpexporter appends/v1/tracesitself. - If you have no Collector yet, adding one just for the evaluation is a small, reversible step. Run it as a sidecar or a single deployment, point your application’s OTLP exporter at it, and fan out from there. Remove it after cutover or keep it as your single egress point.
- Send one request and check it end to end in Rius. The trace tree should look right, the model call should show model and token counts, and cost should appear. If those fields are empty, check that no Collector processor, such as
attributesortransform, strips thegen_ai.*keys. - Name your agent with
service.name. Rius groups traces by agent under that name, so setOTEL_SERVICE_NAMEif your setup does not set one.
What you get
- A like-for-like comparison. Trace trees, token counts and cost come from the same traffic in both tools, so you decide on evidence rather than on a test run.
- Rius cost for those calls, computed by Rius from the model and token counts. It is a list-price estimate in US dollars, so compare it with the Langfuse figure as an estimate and not as a billed amount.
- No application changes while you evaluate. Only the Collector configuration changes.
- A reversible migration. Removing the Rius exporter returns you to the original setup.
When to turn Langfuse off. Compare the two backends on real traffic for a few days: trace counts, token totals and cost. Then move anything that reads from Langfuse, such as dashboards, alerts and internal tools, to its Rius equivalent, or leave it behind on purpose. Last, remove the Langfuse exporter and revoke the Langfuse keys once nothing sends to them. The full list is the cutover checklist in Migrate from Langfuse.
Two things affect timing. Existing traces stay in Langfuse, and Rius starts from the first span you send it. Also, a new organization starts on a trial that lasts 30 days or 500,000 spans, whichever comes first, with no card. A parallel run that outlasts the trial needs a plan, because ingest is refused after the trial without one. Stored data stays readable.
When something else fits
- Keep Langfuse running for scores, annotation queues, LLM-as-judge evals, datasets or prompt management. Rius does not offer them, so send your traces to both tools and keep those workflows where they are.
- If you need to self-host, Rius is a managed service only.
- If you have no use for a parallel run, re-point your OTLP exporter at Rius and cut over directly, as the Langfuse migration guide describes.