How do I move my production and staging environments from Arize Phoenix to Rius?

In Rius, you give production and staging each their own workspace and API key, and you name the agent with service.name instead of a Phoenix project. Your OpenInference instrumentation keeps producing the same spans, so you re-point the exporter at Rius in each environment and set the key for that environment. The Migrate from Arize Phoenix guide covers the full path, and Migrate to Rius covers the other tools.

How it works

Phoenix organizes traces by project. Rius organizes them by workspace and agent, so the environment split moves to a different place.

• Project becomes agent. Rius groups traces by agent name, which defaults to the service.name resource attribute, inside the workspace your API key belongs to. Phoenix’s project_name and openinference.project.name are stored on spans but do not drive grouping.
• Environment becomes workspace. Each trace belongs to one workspace, and the API key that sends it decides which one. Create one workspace and one API key per environment, and production and staging stay separate.
• Environment tags have no counterpart. If you mark the environment with Phoenix metadata or tags, Rius stores them as span attributes you can filter on by key. They do not drive grouping, views or analytics, so they do not replace a workspace.
• Sessions and users carry over. session.id and user.id are the same attributes, so using_session and using_user keep working. Set both on every span of the trace, the root span included.
• Span kinds carry over. AGENT, LLM, TOOL, CHAIN, RETRIEVER, EMBEDDING and RERANKER are read as they are, and LLM spans become generations with model, token and cost analytics.

Cost is computed by Rius from the model and token counts. You never send a cost value.

Set it up

1. Create a workspace and an API key for each environment. Make one for production and one for staging in the Rius console at https://console.rius-glassflow.com. Store each key as RIUS_API_KEY in that environment’s secrets, so the same code sends to the right workspace in each place.

2. Re-point register() and set a service name. If you use phoenix.otel.register(), pass the full traces URL, the protocol and the key in code. Setting only PHOENIX_COLLECTOR_ENDPOINT to the Rius URL sends spans to the wrong port. Without a service.name, traces arrive as unknown_service.

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,
)

3. Or switch to the Rius SDK. If you prefer rius.init(), it installs the same OpenInference instrumentors, and RIUS_API_KEY is usually the only setting because the endpoint defaults to EU ingest. Replace using_session with rius.session and using_user with rius.user in the same change, so spans you start with rius.start_as_current_span or @rius.observe carry the session and user.

import rius
 
rius.init(service_name="my-agent")
 
with rius.session(conversation_id):
    run_agent(message)

4. Start with staging. Send staging traces to Rius first, and keep Phoenix running in parallel by adding Rius as a second span processor with replace_default_processor=False. Check one traced request end to end: the tree, the model and token counts, the cost, and the session and user.

5. Cut over production. Once staging looks right, give production its own key and repeat. Remove the Phoenix exporter and revoke the Phoenix API key when nothing sends to it. The Phoenix migration guide has the side-by-side code and the full cutover checklist.

What you get

• Production and staging traces in separate workspaces, each with its own API key, so a staging experiment never mixes into production numbers.
• The same trace trees you had in Phoenix, with generations, sessions and users read from the attributes you already set.
• Cost per call as a list-price estimate in US dollars, computed from the model and token counts.
• Agents grouped by service.name inside each workspace.
• A reversible migration, because both backends can receive identical spans until you remove the Phoenix exporter.

When something else fits

• Rius has no evals, datasets, experiments, annotations, prompt management or playground, so keep those workflows in Phoenix or a dedicated tool and run both side by side.
• Rius is a managed service only, so a self-hosted Phoenix setup has no equivalent. It also prices at public list prices with no custom model prices.
• Existing Phoenix traces are not imported. Rius starts from the first span you send, so keep Phoenix for the history you need.

Related