MagicMirror²: a modular smart mirror platform for Raspberry Pi and desktop

What MagicMirror² actually solves, and for whom

The project describes itself as an open source modular smart mirror platform that converts a hallway or bathroom mirror into a personal assistant. The problem it addresses is not display hardware but content assembly: a mirror is a fixed surface, and anything you want to see in it has to come from somewhere. MagicMirror² supplies the runtime, the layout engine and a set of default modules, and lets other people supply the rest. The audience is people who already own or intend to build a two-way mirror and want to decide what appears behind the glass. That includes Raspberry Pi owners (the repository topics list raspberry-pi), home automation users who want a wall display, and developers who want to write a module against a documented interface. It is a poor fit for anyone who wants a finished product with a warranty. The README points to a dedicated documentation site for installation instructions rather than containing them, which tells you something about the intended reader: someone willing to leave the README and read structured docs.

Electron as the wrapper, and why there is no browser to install

The README states that MagicMirror² uses Electron as an application wrapper, so no web server or browser installs are necessary. That is the central architectural decision. The entry point in package.json is js/electron.js, and the package exports the same file, so running the project means launching an Electron process that renders index.html and the contents of css/, js/ and modules/. The repository layout separates concerns in a way that maps onto the module system: defaultmodules/ holds the modules shipped with the core, modules/ is where third-party modules are placed, and config/ holds configuration. There is also clientonly/ and serveronly/, which the package.json files array includes for distribution, plus a server script that runs node ./serveronly. That split matters because a module can do work in the browser context, in the Node context, or both, and the two halves communicate. The practical consequence is that a module author is writing JavaScript against an application framework, not against a web page. Translations live in translations/, so module strings can be localized without touching each module's code.

Installing MagicMirror² and getting a first module on screen

The README does not carry install steps. It links to https://docs.magicmirror.builders/getting-started/installation.html for the full documentation including installation instructions, so that page is the authoritative source for prerequisites and platform-specific steps. What the repository does give you is the npm script surface. The package.json defines install-mm, which runs npm install with --no-audit --no-fund --no-update-notifier --only=prod --omit=dev, so a production install deliberately skips development dependencies. A development install is install-mm:dev, which also runs npx playwright install chromium for the test tooling.

npm run install-mm

Running that from the project root installs the runtime dependencies. The flags in the script suppress audit output, funding notices and the update notifier, and restrict the tree to production packages, which is what you want on a Raspberry Pi where disk and build time matter.

Configuration lives in config/config.js. The repository ships a config/ directory, and the docs site is where the file's shape is documented. Before starting the application you can validate that file with the config:check script, which runs node js/check_config.js.

npm run config:check

A successful run means the configuration parses. A failure points at the offending entry, which is cheaper than discovering it after Electron has already taken over the screen.

Starting the application is a matter of choosing the right script for your display stack. The default start script delegates to start:wayland, which sets WAYLAND_DISPLAY and launches Electron with --ozone-platform=wayland.

npm start

On a Raspberry Pi running a Wayland session, that is the path the maintainers wired up as the default. The package.json also contains a server script (node ./serveronly) and a server:watch variant for running the Node side without the Electron window, which is useful when you are debugging a module's server half. Third-party modules go into modules/; the README's own framing is that the platform has a growing list of installable modules, and the docs site covers installation of those separately.

Where MagicMirror² gets in your way

The Electron wrapper is a trade-off, not a free win. You get a consistent rendering target and no browser to manage, but you also inherit a full Chromium process on a device that is often a Raspberry Pi. That is a heavier baseline than a plain web page served to a kiosk browser, and it is the reason the project ships a production-only install script. The second constraint is configuration by JavaScript file. config/config.js is code, not a declarative document, so a syntax error is a startup failure, which is exactly why js/check_config.js exists. Third, the module ecosystem is the product and also the risk: the core ships defaultmodules/, but anything beyond that is third-party code running inside your Electron process. The README does not document a sandboxing model or a module review process, so the trust boundary is whatever you choose to place in modules/. Finally, the README does not document rollback or a downgrade procedure. Releases are versioned (v2.37.0, v2.36.0, v2.35.0 appear in the release list) and CHANGELOG.md exists at the repository root, but if a new version breaks a module you depend on, the recovery path is not spelled out in the README.

MagicMirror² compared with Dakboard and a Home Assistant dashboard

Dakboard is the comparison people search for, and the difference is ownership of the runtime. Dakboard is a hosted service: you configure a screen in someone else's web application and point a browser at it. MagicMirror² is a local application you install and run, which is why the README can say no web server or browser installs are necessary. The trade is that you own updates, module compatibility and uptime. Against a Home Assistant dashboard, the split is different again. Home Assistant is a home automation platform that happens to render a dashboard; MagicMirror² is a display platform that can pull data from wherever you point it. If your mirror's purpose is to control lights and show entity states, Home Assistant already does that and you would be adding a second system. If your purpose is a passive glanceable surface (time, calendar, weather, a photo) that is not tied to an automation hub, MagicMirror² is the more direct tool. The repository topics include both domotics and smarthome, so the project does not position itself against either.

Maintenance, release cadence and the MIT licence

The repository is not archived, and the last push was on 2026-09-20, one day before the date used for this assessment, so the codebase is receiving commits. The release list shows v2.37.0 on 2026-07-01, v2.36.0 on 2026-04-30 and v2.35.0 on 2026-04-01, which is roughly a monthly cadence over that window. Upgrading means pulling the repository and re-running the install script, then checking CHANGELOG.md for breaking changes to module APIs. That is the cost you are accepting: there is no package manager command in the README that upgrades a deployed mirror for you, and the docs site is where upgrade guidance would live. On licensing, package.json declares MIT and LICENSE.md is at the repository root. MIT is permissive: it allows commercial use and modification, and it requires that the copyright notice and permission notice be preserved. It does not grant trademark rights, and it comes with no warranty. Third-party modules in modules/ carry their own licences, which the core licence does not cover; check each one before shipping a mirror to someone else. This is a description of the licence text, not legal advice.

Editorial conclusion

Adopt MagicMirror² if you want a self-hosted display whose content you control through config.js and JavaScript modules, and you are comfortable reading docs.magicmirror.builders rather than a single README. Do not adopt it if you need a managed, zero-maintenance screen with a support contract, or if you cannot keep a Raspberry Pi and its power supply running continuously. Before buying mirror glass, verify two things on your own hardware: that the start:wayland script works on your display server, and that the default modules you plan to show (clock, calendar, weather) load with your own API keys and calendar URLs.

Frequently asked questions

Official sources

1. License: MIT
2. MagicMirrorOrg/MagicMirror on GitHub
3. Project website
4. README
5. Releases