Muximux: A Dashboard That Proxies Stubborn Apps Into Iframes
A self-hosted homelab dashboard with an optional built-in reverse proxy that makes stubborn apps work in iframes
At a glance
- What is it?
- Muximux pairs a self-hosted homelab dashboard with an optional embedding proxy that strips X-Frame-Options and patches fetch() and XMLHttpRequest so apps like Plex load inside a pane. It is for people who work inside their apps, not people who want live widgets on a landing page.
- Who is it for?
- Adopt Muximux if your daily loop is clicking into Sonarr, Radarr or Plex and you are tired of tab sprawl, and if you accept that the embedding proxy is the feature you are really installing. Skip it if you want at-a-glance widgets from qBittorrent or a freeform grid canvas; the README points those users at Homepage and Homarr instead.
- Can I use it commercially?
- Yes, with conditions. GPL-2.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem Muximux Targets: Apps That Refuse to Be Framed
Most self-hosted dashboards are landing pages. You open one, look at widgets, then click through to the app in a new tab and spend the rest of the session there. Muximux inverts that. The README describes the intended user as someone who "spends the day working inside their self-hosted apps, not glancing at widgets on a landing page." Click Sonarr and Sonarr opens inside the dashboard. The stated goal is that you never leave the page.
The obstacle is a single HTTP response header. According to the README, most self-hosted apps set X-Frame-Options: DENY, which makes a browser refuse to render them in an iframe. This is why dashboards that simply point at your apps cannot embed them. Muximux ships an optional embedding proxy whose job is to remove that header, rewrite paths in HTML, CSS and JavaScript, and patch fetch() and XMLHttpRequest at runtime. The README claims this is enough for "even heavy single-page apps" to behave as they do when opened directly, and states plainly that no other dashboard does this and that it is the reason Muximux exists.
That is a narrow audience by design. The README lists Homepage, Homarr, Organizr and Dashy as "excellent tools in this space" and tells readers who already fit one of them to stop reading. The differentiator is not the dashboard chrome. It is the proxy underneath it.
How the Embedding Proxy Actually Works
The mechanism has three parts, all described in the README. First, header stripping: the proxy removes the framing restrictions that block iframe rendering. Second, path rewriting: references to assets in HTML, CSS and JavaScript are rewritten so they resolve through the proxy rather than against the origin app. Third, runtime patching: fetch() and XMLHttpRequest are intercepted so that requests a single-page app issues after load also travel through the proxy instead of hitting the app directly and bypassing the rewrite.
That third step is the one that matters for modern apps. A server-rendered page with static links can be fixed with response rewriting alone. A single-page app that builds API URLs in JavaScript at runtime cannot, because the proxy never sees those URLs in the initial HTML. Patching the request primitives is what closes that gap, and it is also where the fragility lives: any code path that reaches the network without going through fetch() or XMLHttpRequest escapes the rewrite.
The distribution model is deliberately small. The README's summary is "One binary. One port. One YAML config file." The repository topics list Go, Svelte, Caddy and Docker, which suggests a Go backend with a Svelte frontend and Caddy involved in the proxying layer. The README does not spell out the internal request flow beyond the three proxy behaviours above, so treat any finer architectural claim as unverified.
One detail that deserves attention before you install anything: the README carries an AI disclosure stating that Muximux is developed with significant AI assistance (Claude Code) and that all code is reviewed, tested and approved by the maintainer before shipping. Whatever you think of that workflow, it is disclosed rather than hidden, and the repository also carries CI, CodeQL, SonarCloud and Codecov badges plus an OWASP ASVS Level 2 badge pointing at docs/wiki/security.md.
Getting It Running: One Binary, One Port, One YAML File
The README does not include an installation command block in the material available here, so the honest answer on exact invocation is that you should read the repository's own install instructions. What the README does establish is the shape of a deployment: a single binary listening on a single port, configured by one YAML file. The Docker badge points at ghcr.io/mescon/muximux, so a container image is published to GitHub Container Registry under that path.
Configuration is where the interesting decisions happen, and it happens in YAML. Each app you want on the dashboard needs an entry, and the embedding proxy is optional per the README's framing of it as a built-in but not mandatory component. The practical question for each app is whether to route it through the proxy or point at it directly. Direct pointing is simpler and keeps the app's own origin semantics intact, but any app sending X-Frame-Options: DENY will not render. Routing through the proxy is what makes those apps embeddable, at the cost of putting a rewriting layer between the browser and the app.
There is an onboarding wizard. The screenshot set includes welcome, security, app catalog, apps configured, style, theme and done steps, plus an app catalog screen implying that common homelab apps are pre-listed for selection rather than typed in from scratch. Beyond that, the README does not document individual config keys in the material provided, so I am not going to invent key names. If you need the exact schema, the repository is the source.
Operationally, the one-port claim is worth taking seriously as a constraint and a convenience. A single port means one thing to reverse proxy from the outside, one thing to firewall, and one thing to expose over a VPN. It also means the dashboard and every proxied app share a failure domain: if the Muximux process stops, you lose access to the apps through it, though not the apps themselves.
Where the Proxy Breaks, and Who Should Not Use This
A proxy that rewrites HTML, CSS, JavaScript and runtime network calls is doing something inherently approximate. The README's own framing gives the failure mode away: it says the proxy makes "even heavy single-page apps work the way they do when opened directly." That is a claim about coverage, and coverage in a rewriting proxy is never total. Apps that construct URLs in ways the patched primitives do not intercept, or that rely on origin-specific behaviour such as cookies scoped to a particular host, are the likely candidates for breakage. I have not run this, so I cannot tell you which apps fall over. What I can tell you is that the category exists and that the README does not publish a compatibility list in the material available.
Security is the second consideration, and it cuts both ways. Stripping X-Frame-Options is the whole point, but those headers exist for a reason: they prevent a page from being framed by another origin. When Muximux removes them, it is deliberately weakening a browser protection for apps it proxies. The consequence is that anything able to reach the Muximux port can potentially frame those apps. The README links an OWASP ASVS Level 2 badge to docs/wiki/security.md, which is the document to read before exposing the port beyond a trusted network. This is not a reason to avoid the project, but it is a reason not to put it on the public internet without thinking about authentication.
The third limitation is scope by omission, and the README is unusually direct about it. Muximux does not pull live widgets from Sonarr or qBittorrent, and it does not have a freeform grid editor for arranging resizable widgets on a canvas. If either of those is what you want from a dashboard, this is the wrong tool and the README says so before you install it.
Homepage and Homarr: Different Answers to the Same Question
The README names Homepage, Homarr, Organizr and Dashy as alternatives, and the useful comparison is with the first two because they sit at opposite ends of the same design axis.
Homepage is a widget dashboard. It queries your services and renders their current state on a landing page: queue depths, download progress, container health. You look at it, you learn something, you leave. Muximux does not do this at all, and the README concedes that Homepage "is lovely at that." The difference in approach is information versus workspace. Homepage tells you what is happening. Muximux puts you inside the app where you would act on it.
Homarr is built around a freeform grid where you arrange resizable widgets on a canvas. That is a layout-first design: the dashboard itself is the artefact you shape. Muximux's layout features, judging from the screenshot list, are split view (horizontal and vertical), themes, a theme customizer and a command palette. Those are workspace affordances, not canvas affordances. You are arranging panes to work in, not composing a wall of tiles.
Neither alternative solves the iframe problem, and that is the honest summary of the comparison. If your apps embed fine, or if you do not care about embedding them, Muximux's central feature buys you nothing and you are choosing between dashboards on layout and widget grounds, where the alternatives are stronger. If your apps set X-Frame-Options: DENY and you want them in a pane anyway, the alternatives do not offer a path and Muximux does.
Licence, Maintenance and the Cost of the Go Binary
Muximux is GPL-2.0. For a self-hosted tool you run yourself, that is unremarkable: you can run it, modify it and redistribute it under the same terms. The obligation that matters is copyleft on distribution. If you fork Muximux and ship the modified binary to others, the GPL requires you to make the corresponding source available under GPL-2.0. Running it privately on your own hardware triggers nothing. This is a description of the licence, not legal advice; if you plan to redistribute a modified build, read the licence text or ask someone qualified.
The maintenance picture visible in the repository metadata is active. The last push is dated 2026-09-09, and the release cadence shows v3.4.0 on 2026-09-03, v3.4.1 two days later on 2026-09-05, and v3.3.3 before that on 2026-07-29. The repository is not archived. The maintainer has also wired up CI, CodeQL, SonarCloud quality and security gates, and Codecov, which are the kind of checks that cost time to keep green and tend to disappear on abandoned projects.
The upgrade cost is the part that is genuinely low here, and the README's own summary explains why: one binary, one port, one YAML config file. There is no database migration to run and no multi-service stack to coordinate, based on what the material describes. You replace the binary or pull a new image tag, restart, and the YAML config carries over. The residual risk is that a config schema change between minor versions forces a YAML edit, and the release notes are the place to check that before upgrading. The AI-assistance disclosure is also a maintenance consideration in a mild sense: it tells you the review process is a single maintainer approving generated code, which is a real constraint on how much independent scrutiny any given change receives.
Editorial conclusion
Adopt Muximux if your daily loop is clicking into Sonarr, Radarr or Plex and you are tired of tab sprawl, and if you accept that the embedding proxy is the feature you are really installing. Skip it if you want at-a-glance widgets from qBittorrent or a freeform grid canvas; the README points those users at Homepage and Homarr instead. Before committing, verify that your specific apps survive the proxy path rewriting, and read docs/wiki/security.md, since a proxy that strips framing headers changes the trust boundary of everything behind it.
Community notes