Hosting

Studio is served from your ASP.NET Core application.

You choose the path. The same host that owns your agents, tools, workflows, and Context Spaces serves the developer UI and runtime APIs.

Enable Studio

using Runiq.Core;

var app = builder.Build();

app.UseRuniqDashboard(options =>
{
    options.Path = "/studio";
    options.Title = "Runiq Studio";
});

app.Run();

The default path is /runiq.

You can choose a path that fits your app:

app.UseRuniqDashboard(options =>
{
    options.Path = "/dashboard";
    options.Title = "Runiq Workflow Travel Planner";
});

If Path = "/dashboard", open /dashboard on the same host. If Path = "/studio", open /studio.

The root path / is not supported for Studio.

The screenshots in these docs are taken from sample apps that use /dashboard. That is the configured sample path, not a separate product surface. If your app configures /studio, the same UI and APIs are served under /studio.

What gets mapped

UseRuniqDashboard maps the Studio UI, static assets, metadata APIs, agent chat APIs, tool run APIs, workflow APIs, and Context Space read APIs under the configured base path.

With Path = "/studio", Studio uses routes such as:

/studio
/studio/metadata/agents
/studio/api/agents/{agentId}/chat
/studio/api/tools/{toolName}/run
/studio/api/workflows/{workflowId}/run

Why this helps developers

The Studio deployment model matches the Runiq runtime model.

Your app owns the agents. Your app owns the tools. Your app owns the Context Spaces. Studio runs from that same app, so local development and debugging do not require a separate service or hosted control plane.

For local development, run the sample or your application in Development and open the configured path. This keeps Studio connected to the same registrations, configuration, and dependency injection graph that the runtime uses.