I was wondering if there are any plans to release a self-hostable version of the LiveKit dashboard?
For teams running LiveKit in their own infrastructure, it would be really useful to have a local dashboard for things like project visibility, room/session monitoring, participant debugging, usage insights, and general operational oversight without relying on the hosted cloud dashboard.
Is this something on the roadmap, or is the recommended approach to build custom internal tooling on top of the LiveKit APIs/metrics?
Curious to hear if others would find this useful as well.
Personally I’ve looked into this myself some time ago and I think in this situation its best to build your own custom internal tooling on top of your self hosted livekit infra. Ideally you could build an MCP based UI that could connect to Livekit’s MCP and will give you and your team the ideal observability that you lot are looking for. It’s just an idea tho but what do you think?
When you say “LiveKit’s MCP”, do you mean the current LiveKit docs MCP, or is there/are there plans for an MCP server that can expose runtime/project data from a self-hosted LiveKit deployment?
My understanding is that the current MCP is mainly for docs/code examples/changelogs, not operational access to rooms, participants, SIP state, metrics, logs, agent sessions, etc. So for a self-hosted dashboard I’d still expect most of the work to be around wiring together LiveKit server APIs, Prometheus metrics, logs/traces, and whatever app-level call/session state we persist ourselves.
I like the idea of an MCP layer as an operator assistant on top of that, but I’m a bit cautious about making it the primary observability interface. For debugging production calls, I’d still want deterministic views first: active rooms, participants, SIP/telephony state, agent lifecycle, errors, recordings, transcripts, latency, and resource metrics. Then MCP/AI could help answer questions over that data.
Have you seen any concrete examples of someone building this kind of MCP-backed operational UI for LiveKit? Or are you thinking more conceptually: build our own internal MCP server around the LiveKit APIs and metrics, then connect a UI/agent to that?
You’re welcome Robbe!
Yeah i was suggesting to build your own custom internal MCP Server just so it serves your team the exact way you all want it. Here’s a flowchart example i made for you in Fig Jam.
@Robbe, you’re right to be cautious about leading with MCP for operations. There’s no official livekit-mcp for runtime data today, only the docs MCP, which lines up with what @CWilson said.
What self-hosting already gives you, all without MCP: server APIs (RoomService, EgressService, IngressService, SIPService, AgentDispatchService) for live state, Prometheus metrics for resource counters (active expansion in flight, e.g., Prometheus Metrics for auth · Issue #3651 · livekit/livekit · GitHub), webhooks for the event stream, and session.on("metrics_collected", ...) for per-turn agent latency. The two genuine Cloud-only gaps are per-session ICE traces and Agent Insights.
A custom MCP wraps the same APIs; it adds query ergonomics, not data. Path A in Elijah’s diagram is the foundation; Path B is an assistant on top.
If you’re starting now: Next.js + server SDK + webhooks > Postgres + Grafana on Prometheus.
Hey Elijah, thank you for your clarification! This seems like an awesome idea. I personally use a lot of AI in the development process, so this aligns very well with my workflow. Ill definitely save your image for when we will start development on our full self-hosted transition!
P.S. Sorry that i responded a bit later, I didn’t have time to take a really good look at it and discuss it with my team until now.
Great article, Muhammad, I really enjoyed reading through it! The dashboard you built for monitoring LiveKit metrics looks really useful. Do you know if it’s also possible to capture specific events for each session in a self-hosted dashboard in the same manner as shown in the attachment below?
Glad it was useful, @Robbe, and yes, you can. The per-call timeline in that screenshot is just two event streams keyed by room_name, and on self-host you have both.
Server webhooks, room / participant / track lifecycle. Wire WebhookReceiver from the server SDK into a /webhooks endpoint and store the JSON in Postgres keyed by room_name:
AgentSession events, per-turn slice, emitted inside your worker. Push these to the same Postgres on the same room_name:
agent_state_changed, user_state_changed
overlapping_speech, agent_false_interruption
function_tools_executed
conversation_item_added, carries per-turn latency in item.metrics (note:metrics_collected is now deprecated; prefer conversation_item_added, correcting myself from earlier in this thread)
Render it. A SQL view ordered by created_at over both tables gives you the timeline. Grafana’s state-timeline panel or a custom Next.js page lands close to the Cloud Calls view.
