m-ui compared with other panels
If you are choosing between sing-box and Xray panels, this page lists what each project states about itself. Facts below were checked against each project's README on 2026-09-05; anything a README does not state is marked Unknown rather than guessed.
The short version
Most panels are config-driven: you edit inbounds, outbounds and routing rules that map one-to-one onto the core's JSON, and the panel restarts or reloads an external core process. m-ui is line-driven: one record — protocol + port → exit — is rendered into the sing-box config for every server it is deployed on, the core runs inside the panel process, and changes are applied by the smallest reload that covers them. That is the whole difference in philosophy; the table shows how it plays out in features.
Feature table
| m-ui | 3x-ui | s-ui | Marzban | Hiddify-Manager | |
|---|---|---|---|---|---|
| Core | sing-box | Xray-core | sing-box | Xray-core | Xray and sing-box |
| Core runs | Embedded in the panel binary | External process managed by the panel | Unknown | External process (Xray installed separately) | Unknown |
| Config model | Lines (protocol + port → exit) | Inbounds / outbounds / routing | Inbounds / outbounds / routing | Inbounds (Xray config), per-user protocol selection | Unknown |
| Change applied without dropping other users | Yes: user and upstream changes hot-swap; only line changes restart | Unknown | Unknown | Unknown | Unknown |
| Config validated before save, rollback on failed start | Yes (sing-box dry run + rollback) | Unknown | Unknown | Unknown | Unknown |
| Multi-server from one panel | Master / node: push every 5 s, central quota and device limits | Yes: manage multiple servers, clone inbounds onto other nodes | Unknown | Yes: Marzban-node | Unknown |
| Subscription formats | Universal links, Clash / Mihomo, sing-box JSON; landing page | Raw, JSON, Clash; custom page templates | Link, JSON, Clash; external links | V2ray-style, Clash, ClashMeta | Dedicated clients + subscriptions |
| Traffic quota / expiry | Yes / yes, periodic reset | Yes / yes, renewal cycles | Yes / yes | Yes / yes, periodic limits | Yes / yes |
| Device limit | By source IP, counted across all servers | IP limit and HWID limit | Unknown | Unknown | Unknown |
| Per-user speed limit | Yes (up / down) | Unknown | Unknown | Unknown | Unknown |
| Resellers with own panel | Yes | Unknown | Unknown | Unknown | Unknown |
| Deployment | One static binary + SQLite | Binary + Xray, or Docker | Binary, or Docker | Python app + Xray, Docker | Installer script, Docker |
| License | GPL-3.0 | GPL-3.0 | GPL-3.0 | AGPL-3.0 | GPL-3.0 |
When m-ui is not the right pick
- You need Xray-only features — XTLS flows beyond Vision, XHTTP, WireGuard or TUN inbounds. m-ui is sing-box only and does not expose those.
- You want the largest community and the most third-party tutorials. 3x-ui has years of head start; m-ui is new and maintained by one person.
- You prefer editing the core's JSON directly. m-ui deliberately hides it behind lines; an "advanced" JSON field exists per line, but the routing table is not yours to edit.
When it is
- You run more than one server and want users, quotas and device limits to be one thing, not one per server.
- You change users often and do not want everyone else reconnecting every time.
- You want one binary you can copy, back up and update without a container runtime or a separate core to keep in step.
- You resell: separate reseller panels with budgets, own plans and own landing copy.
Migrating
m-ui imports a compatible legacy panel database and keeps ports, credentials and subscription paths, so existing clients keep working after a switch. It does not claim compatibility with every panel above — check the importer report on a copy of your database first. See Getting started.
Sources
Checked 2026-09-05. Corrections welcome in Discussions — the goal is accuracy, not winning a table.