How do I move my production and staging environments from LangSmith to Rius?
Rius separates production and staging by giving each environment its own workspace and API key, and each LangSmith project becomes an agent named by service.name. You swap the LangSmith environment variables for RIUS_API_KEY and one rius.init() call. Start with staging, run both backends side by side, then cut production over. The full walkthrough is in Migrate from LangSmith to Rius, and the wider picture is in Migrate to Rius.
How it works
LangSmith groups runs into projects, and you usually point each environment at a different project, such as my-agent and my-agent-staging. Rius maps the pieces differently:
- Project becomes agent. Rius groups traces by agent, named by
service.name(service_nameinrius.init()). - Environment becomes workspace. Each trace belongs to one workspace, and its API key decides which one. Create one workspace and one API key for production and another for staging.
- Thread becomes session. A
thread_idorsession_idin LangSmith metadata becomeswith rius.session(thread_id):, which stampssession.idon every span in scope, child spans included. - Metadata and tags become span attributes. Rius has no separate tag concept, so use an attribute.
- Run becomes span. Run types map to span kinds:
llm,chain,tool,retrieverandembeddingcarry over, and Rius addsAGENT.
Because the key picks the workspace, the same code runs unchanged in both environments. Only the key you deploy with differs.
Set it up
-
Create two workspaces and two API keys, one for staging and one for production. Rius API keys start with
ri_. -
Install the SDK for a LangChain or LangGraph app (Path A in the migration guide):
pip install "glassflow-rius[langchain]" -
Replace the LangSmith variables in each environment. Staging gets the staging key and production gets the production key. The
LANGSMITH_PROJECTsetting is replaced byservice_namein code:# Before: LangSmith export LANGSMITH_TRACING=true export LANGSMITH_API_KEY="lsv2_..." export LANGSMITH_PROJECT="my-agent" # After: Rius export RIUS_API_KEY="ri_..." -
Call
init()once at startup:import rius client = rius.init(service_name="my-agent")Your chains, agents and graphs stay as they are. In a short-lived script, call
client.flush()before it exits. -
If you use
@traceableor the client wrappers, swap them:@traceablebecomes@rius.observe,run_type="tool"becomeskind=rius.SpanKind.TOOL, andwrap_openai(OpenAI())becomes a plainOpenAI(), becauserius.init()instruments the library for the whole process. -
Move threads to sessions. Wrap each conversation turn in
rius.session(thread_id). -
Cut over staging first. Run the Rius SDK in staging while production keeps reporting to LangSmith. Leaving
LANGSMITH_TRACING=trueset also keeps LangSmith running next to Rius in the same process. Check that the trace tree matches what you see in LangSmith, that each model call has its model and token counts, and that cost appears. Compare both backends on real traffic for a few days, then repeat for production. -
Clean up. Unset
LANGSMITH_TRACING, remove@traceableand the wrappers, and revoke the LangSmith keys once nothing sends to them.
If you cannot change code yet, LangSmith’s own OpenTelemetry export can send to Rius with the OTEL_EXPORTER_OTLP_* variables, using langsmith 0.4.25 or newer. Set OTEL_SERVICE_NAME to your agent name, because LangSmith defaults it to langsmith. Use the staging key in staging and the production key in production. This path sends the trace tree, model calls with tokens and cost, and tool spans, but not inputs, outputs or messages. Thread IDs arrive as langsmith.metadata.thread_id, so traces are not grouped into sessions. It also gives no view of live agent processes. Treat it as a bridge, then move to the SDK.
What you get
- Production and staging traces kept apart, because each workspace holds only the traces sent with its key.
- The same nested trace tree you know from LangSmith, with each model call as a generation carrying model, tokens and cost. Cost is a list-price estimate in US dollars that Rius computes from the model and token counts.
- Sessions, users, and alerts on top of the traces.
- Which agent processes are alive, when you use the Rius SDK.
- A reversible migration: nothing forces a hard switch until you remove LangSmith from your code.
Some LangSmith pieces have no counterpart in Rius:
- Feedback scores, annotation queues, datasets, experiments and evaluators.
- Prompt Hub and the Playground. Prompt content on spans is captured, but there is no registry.
- Hosting or running agents. Rius observes them wherever they run.
- Self-hosting. Rius is a managed service only.
- Importing history. Existing traces stay in LangSmith, and Rius starts from the first span you send.
When something else fits
If evaluations, datasets or annotation queues are central to how you validate staging before production, keep LangSmith for those and use Rius for tracing, cost and alerts. If you cannot touch code yet, the OpenTelemetry export bridge lets you evaluate Rius first.