How do I move my projects from Langfuse to Rius?

Rius has no separate project object: each Langfuse project becomes an agent, named by the service.name on its traces, and each environment gets its own workspace and API key. You rename nothing in your traces beyond that name, and you re-point your exporter or swap the SDK. Existing traces stay in Langfuse, and Rius starts from the first span you send it. The full walkthrough is in Migrate from Langfuse to Rius.

How it works

A Langfuse project holds traces, and Rius organizes the same traces in two levels:

• Agent: Rius groups traces by agent, named by service.name. One Langfuse project usually becomes one agent. If a project holds several distinct agents, give each its own service.name and they appear separately.
• Workspace: each trace belongs to one workspace, set by the API key that sends it. Use a workspace and API key per environment, such as production and staging, instead of one Langfuse project per environment.

The other concepts inside a project map directly: traces, spans, generations, sessions and users carry over. A Langfuse user (user_id) becomes user.id, and each user’s cost, failures and traces appear on the Users page.

Your migration path depends on how you instrument today, as covered in Migrate to Rius:

• You already send OTLP to Langfuse (OpenLLMetry, OpenInference, a vanilla OpenTelemetry SDK, or a Collector): keep the instrumentation and change the exporter endpoint and auth. Langfuse authenticates with Basic auth from a public and secret key pair. Rius takes one API key as a Bearer token.
• You use the Langfuse SDK: swap it for the Rius SDK, whose decorators, context managers and session scope have the same shape.

In both cases the project’s identity comes from service.name, so that is the one value to decide per project.

Set it up

1. List your Langfuse projects and pick an agent name for each. The name becomes service.name. If you use one project for production and another for staging, plan one Rius workspace per environment instead, each with its own API key.
2. Create the workspaces and API keys. Mint one key per workspace. Rius keys start with ri_.
3. Re-point the exporter if you send OTLP. Set the endpoint, protocol and Bearer header to Rius:

export OTEL_EXPORTER_OTLP_ENDPOINT="https://ingest.eu.console.rius-glassflow.com"
export OTEL_EXPORTER_OTLP_PROTOCOL="http/protobuf"
export OTEL_EXPORTER_OTLP_HEADERS="authorization=Bearer <your API key>"

4. Set the agent name for each project. If your setup does not already set service.name, set OTEL_SERVICE_NAME for each service. With the Rius SDK, pass it to init, as in rius.init(api_key="ri_...", service_name="my-agent").
5. Port Langfuse SDK calls if you use that SDK. In Python, @observe() becomes @rius.observe, propagate_attributes(session_id=...) becomes with rius.session(session_id):, and propagate_attributes(user_id=...) becomes with rius.user(user_id):. If you call OpenAI, Anthropic or another supported library, rius.init() instruments it, so you may not need to port generation blocks by hand.
6. Run both backends side by side. Add Rius as a second exporter in your Collector, or run the swapped SDK in one service while the rest still report to Langfuse. Compare trace counts, token totals and cost for a few days on the same traffic.
7. Cut over. Remove the Langfuse exporter or SDK, then revoke the Langfuse keys once nothing sends to them.

The Langfuse migration guide has the Collector fan-out configuration and the full Python API mapping.

What you get

• Each former project shows as an agent in Rius, named by the service.name you chose, with its traces, sessions and users.
• One workspace and API key per environment, so production and staging traces stay apart.
• Model, token and cost analytics. Rius computes cost from the spans, as a list-price estimate in US dollars, so you never send a cost value.
• A reversible migration: you can keep sending to Langfuse until you revoke its keys.

Three things have no counterpart. Existing traces stay in Langfuse, because Rius does not import historical data. Rius has no scores, evals, datasets or prompt management, so a project that relies on them keeps those workflows in Langfuse or another tool. Rius is a managed service only, with no self-hosted option.

When something else fits

If scores, annotation queues, evals, datasets or a prompt registry are central to how a project works, keep that project’s quality workflow in Langfuse and send its traces to both tools with the side-by-side setup. If you need to bring old traces across, Rius cannot do that, so plan to keep Langfuse readable for as long as you need the history. For other tools, start from Migrate to Rius.

Related