How do I move my historical traces from Langfuse to Rius?

Rius does not import historical traces from Langfuse. Rius starts from the first span you send it, and your existing traces stay in Langfuse. To migrate, you send new traces to Rius and run both backends side by side until you cut over. Because both tools are OpenTelemetry-based, this is usually a routing change rather than a re-instrumentation.

How it works

Rius has no import path for another tool’s stored data, so the migration moves your traffic, not your archive. Each new span you send arrives in Rius as a trace with sessions, users, token counts and server-side cost. Your old traces remain readable in Langfuse for as long as you keep that project.

The concepts map like this:

• Trace is a trace in Rius, with the same tree view.
• Project becomes an agent, named by service.name. Give each environment, such as production and staging, its own workspace and API key.
• Observation (span) is a span. Observation (generation) is a generation, a span with model, tokens and cost.
• Session is a session.
• User (user_id) becomes user.id. Set it with rius.user(...), or on every span of the trace, root included, from your own instrumentation.

These have no counterpart in Rius:

• Scores and annotation queues
• Evals (LLM as judge)
• Datasets and experiments
• Prompt management. Prompt content on spans is captured and inspectable, but there is no registry.
• Self-hosting. Rius is a managed service only.
• Importing historical data

For the full walkthrough of both paths, see Migrate from Langfuse. The overview of every supported source tool is Migrate to Rius.

Set it up

1. Create a Rius workspace and an API key. A new organization starts on a trial of 30 days or 500,000 spans, whichever comes first, with no card. That gives you room to compare both backends on real traffic.

2. Choose how new traces reach Rius.

   • If you send OTLP to Langfuse (OpenLLMetry, OpenInference, a plain OpenTelemetry SDK or a Collector), keep your instrumentation. Change OTEL_EXPORTER_OTLP_ENDPOINT to https://ingest.eu.console.rius-glassflow.com, set OTEL_EXPORTER_OTLP_PROTOCOL to http/protobuf, and replace the Basic auth header with authorization=Bearer followed by your Rius API key in OTEL_EXPORTER_OTLP_HEADERS.
   • If you use the Langfuse SDK, swap it for the Rius SDK. @observe() becomes @rius.observe, start_as_current_observation(as_type="span") becomes rius.start_as_current_span(name), and generations use rius.start_as_current_generation(...). Usage moves from usage_details to gen.set_usage(input_tokens=..., output_tokens=...). The decorator has no generation mode, so call the generation context manager inside the function.

3. Send to both backends for a while. If you already run an OpenTelemetry Collector, add Rius as a second exporter. Use the otlphttp exporter, because Rius takes OTLP over HTTP and not gRPC:

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]

4. Verify one traced request in Rius. Check that the trace tree looks right, the generation shows model and token counts, and cost appears. If analytics fields are empty, check which attribute convention your instrumentation uses.

5. Cut over. Compare trace counts, token totals and cost for a few days. Then move anything that reads from Langfuse, such as dashboards or alerts, to its Rius equivalent. Remove the Langfuse exporter or SDK. Revoke the Langfuse keys only once nothing sends to them.

What you get

• A clean start in Rius with the same traffic you send Langfuse today, grouped by agent, session and user.
• Cost per call computed by Rius from the model and token counts. These are list-price estimates in US dollars, so you never send a cost value.
• A parallel run, so you can compare both backends on identical spans before you decide. The migration is reversible until you revoke your Langfuse keys.
• Your pre-migration history kept where it already is, in Langfuse, so you can still look things up there.

When something else fits

If you need your old traces searchable next to new ones in a single tool, Rius cannot do that today, so keep Langfuse for the historical period. If scores, evals, datasets or prompt management are part of how you work, keep those workflows in Langfuse and send your traces to both tools.

Related