How do I move my projects from Arize Phoenix to Rius?

In Rius, a Phoenix project becomes an agent named by the service.name resource attribute, so you move a project by setting service.name and pointing your exporter at Rius. Keep your OpenInference instrumentors, change the endpoint and key, and give each environment, such as production and staging, its own workspace and API key. Historical traces stay in Phoenix, and Rius starts from the first span you send.

How it works

Rius has no project object. It groups traces by agent name, which defaults to the service.name resource attribute, inside the workspace your API key belongs to. Phoenix’s openinference.project.name is stored on spans but does not drive grouping.

This is how each part of a Phoenix project maps over:

• Project becomes an agent, named by service.name. Use your Phoenix project name as the value to keep names familiar.
• Environments kept as separate projects become separate workspaces, each with its own API key. The key decides the workspace a trace lands in.
• Traces and span kinds carry over as they are. AGENT, LLM, TOOL, CHAIN, RETRIEVER, EMBEDDING and RERANKER are read as-is.
• LLM spans are read as generations, so they get model, token and cost analytics. Rius computes cost from model and token counts, so you never send it.
• Sessions and users keep the same session.id and user.id attributes.
• Metadata and tags are stored as span attributes and can be filtered by key. They have no dedicated views.

Because Phoenix and Rius both read OpenInference spans, the migration is a routing change and not a re-instrumentation. The Migrate to Rius overview covers the general approach.

Set it up

1. Create a workspace and API key for each environment. If you used one Phoenix project per environment, create one Rius workspace per environment and mint a key in each. Store each key as RIUS_API_KEY in that environment.
2. Choose a service.name for each project. Without one, traces arrive as unknown_service. If you use phoenix.otel.register(), pass a resource, or set OTEL_SERVICE_NAME.
3. Re-point the exporter. With register(), pass the full traces URL, the protocol and your key in code:

import os
 
from opentelemetry.sdk.resources import Resource
from phoenix.otel import register
 
tracer_provider = register(
    endpoint="https://ingest.eu.console.rius-glassflow.com/v1/traces",
    protocol="http/protobuf",
    api_key=os.environ["RIUS_API_KEY"],
    batch=True,
    resource=Resource.create({"service.name": "my-agent"}),
    auto_instrument=True,
)

Setting only PHOENIX_COLLECTOR_ENDPOINT to the Rius URL sends spans to the wrong port, so pass endpoint and protocol in code. Use batch=True in production, because the default exports each span synchronously as it ends. 4. Or switch to the Rius SDK. Replace register(project_name=...) with rius.init(service_name=...), which turns on the installed instrumentors for you. Replace using_session and using_user with rius.session and rius.user in the same change, so the root span carries the session and user too. 5. Run both backends for a while. Add Rius as a second span processor with replace_default_processor=False, so Phoenix keeps receiving spans. The Phoenix migration guide has the full side-by-side code, the OTLP exporter setup for a plain TracerProvider and the cutover checklist. 6. Check the agent. Agents are found from traces with no registration. Open the Agents page, confirm each project’s agent appears under the name you chose, and check one trace for its model, tokens, cost, session and user.

What you get

• Each Phoenix project appears as an agent, and each environment sits in its own workspace.
• The same OpenInference spans you send today, now with session and user grouping, server-side cost estimates and alerts.
• Cost is a list-price estimate in US dollars. A model Rius does not know gets an empty cost, not zero.
• Heartbeats and live views, if you use the Rius SDK.
• A reversible move. You can send to both backends until you remove the Phoenix exporter.

Some Phoenix features have no counterpart in Rius:

• Evals, datasets and experiments.
• Annotations and feedback on spans.
• Prompt management and the prompt playground. Prompt content on spans is captured, but there is no registry.
• Self-hosting. Rius is a managed service only.
• Custom model prices.
• Import of historical Phoenix traces.

When something else fits

• If evals, datasets or annotations are central to your workflow, keep Phoenix for those and run Rius beside it, as the Phoenix migration guide describes.
• If you need to self-host your observability backend, Rius does not fit, because it is managed only.

Related