MediaMTX Dashboard Roadmap

[PsymoNiko]

[mediamtx-dashboard] Roadmap: Moving Toward a Full-Featured Web UI

Category: General
Discussion link: #5128

---

Hello everyone,

Building on the ongoing conversation in this discussion (#5128), I'd like to share a formal roadmap for the MediaMTX Dashboard project.

The goal is to evolve mediamtx-dashboard from a standalone tool into a seamlessly integrated, first‑class web interface for MediaMTX. I believe a polished, full‑featured UI would benefit the entire community, just as discussed in previous threads (e.g., #1440, #5230, #5238). The discussion has shown a clear need for such a tool, and many community members have expressed interest in sponsoring or contributing to its development.

---

✅ Current Status

The dashboard is already functional with these key features:

• ✅ Real‑time stream monitoring (active paths, bitrates, client connections)
• ✅ Full path and global configuration editing via UI
• ✅ Persistent config writes with backup/restore (survives server restarts)
• ✅ Built‑in Prometheus + Grafana monitoring stack
• ✅ Docker deployment support (development and production)
• ✅ Basic authentication integrated with MediaMTX's internal user database

You can try it today: GitHub - PsymoNiko/mediamtx-dashboard

---

🚀 Roadmap

The roadmap is organized into six phases, reflecting both immediate priorities and the long‑term vision of becoming the official web UI bundled with MediaMTX.

✅ Phase 1: Foundation (Completed)

• Next.js + TypeScript architecture
• Core stream monitoring (paths, bitrates, client connections)
• Docker Compose setup for development and production
• Prometheus + Grafana monitoring integration
• Basic configuration management UI

🚀 Phase 2: Persistence & Configuration (In Progress)

• Critical: Implement YAML config backup before writes (in progress)
• Critical: Enable saving API‑added paths to persistent storage (in progress)
• Config restore/rollback UI
• Configuration wizard for first‑time users

The ability to save configuration changes so they survive server restarts is the most requested feature from the community and a prerequisite for real‑world deployment.

🔐 Phase 3: Authentication & Authorization (Planned)

• Integrate with MediaMTX's internal user database (existing users: section)
• Login screen and session management
• Role‑based access control (Admin vs. Viewer)
• Restrict stream access by user role

MediaMTX already supports a robust authentication system with internal credentials, external HTTP callbacks, and JWT tokens. The dashboard will initially leverage the internal database and then expand to support other methods.

🎬 Phase 4: In‑Dashboard Video Player (Planned)

• Research optimal player (hls.js / video.js / WebRTC)
• Implement single‑stream viewing modal
• Add multi‑stream NVR‑style grid view
• Support WebRTC for ultra‑low latency viewing

🔌 Phase 5: Full MediaMTX Integration (Planned)

• Support editing of all global config properties
• Support path defaults and user configuration UI
• Align with MediaMTX's unified HTTP service architecture (per Is it possible to use MediaMTX logo as a customised logo for its UI panel? #5128)
• Package dashboard as a single‑file embeddable asset

🌟 Phase 6: Advanced Features & Polish (Planned)

• Stream recording management UI
• WebHook event viewer
• Dark/light theme toggle
• Internationalization (i18n) support
• Comprehensive user documentation

---

📅 Milestones & Timeline

Milestone	Target	Key Deliverables
Alpha Release	Q3 2026	Working config persistence + basic auth
Beta Release	Q4 2026	Full config editing + in‑dashboard player
v1.0 Stable	Q1 2027	Production‑ready with all Phase 1‑4 features
Official Integration	TBD (post MediaMTX v2.0)	Dashboard bundled with MediaMTX binary

---

🤝 Community Collaboration Welcome

Following the maintainer's guidance that "contributions from the community will always be welcome and reviewed with high priority", I'm inviting help in these areas:

• Video player integration – Help select and implement the best streaming player
• RBAC implementation – Design and code role‑based access controls
• Testing – Write unit and integration tests
• Documentation – Improve user guides and API documentation

---

🔗 Project Links

• Repository
• Roadmap Document
• Open Collective (sponsorship)

---

💬 Let’s Discuss

I'd love to hear your feedback, questions, or ideas. Specifically:

1. Maintainers: How can this dashboard best align with your vision for a built‑in UI? Are there technical constraints or preferences I should consider?
2. Other dashboard authors (e.g., mediamtx-ui, mediamtx-GUI): Would you be open to collaboration or sharing approaches?
3. Community: Which features would you prioritize? Is there anything missing from this roadmap?

Thank you for your time, and I look forward to building something great together.

[seekwhencer]

Hey,

i have no time. sorry. but tried to run the dev compose. i'm running my dev server (second machine) with jwilders nginx reverse proxy. and got a "bad gateway". the next server does things... the request is refused. why? i think it could be a allowed proxy setting...

i'm working not bare metal. i'm working in containers. every time.

By my experience while developing my simple media mtx dashboard: i had an insight: the tool needs a "zero config startup" and the app must be used for the very first configuration steps.

You need to consider synchronization between different frontend instances. Ideally, each client receives updates pushed from the server, and the UI updates itself accordingly “as if by magic.” That’s a fairly important feature for me. I tried to implement it—but messed it up. I’m not happy with my solution. However, I do have some ideas on how to approach it.

Does it really need SSR? I don’t think so. CSR is completely sufficient and significantly reduces complexity. I think what’s needed is a dedicated frontend API server and a CSR application.

[PsymoNiko]

Thank you so much for taking the time to test the dev compose setup and for sharing such detailed feedback! 🙏

I’m genuinely sorry you had to wrestle with that "bad gateway" issue—especially as you’re running a second‑machine setup with jwilders’ nginx reverse proxy. That kind of environment can be tricky, and the error you described (request refused) is never fun.

The good news is that the fix is now included in the latest release (v0.1.1). 🎉
You can immediately run the fixed version with a single command (typo fixed 😉):

docker-compose -f docker-compose.dev.yml up

No more blocked requests or painful proxy tuning – just a smooth, zero‑config startup experience.

Thanks again for your patience and for helping make the dashboard better. I really appreciate your insights about push‑based updates and reducing complexity – they’re already influencing the next milestones!

Let me know if you run into anything else. Cheers! 🚀