What I ended up with instead:

• MagicMirror runs as a single Docker container on a separate, more capable Pi on the same home network , completely headless, no monitor attached.
• The Pi with the physical monitor doesn’t run MagicMirror at all anymore. It just runs a browser in kiosk mode, pointed at a small local reverse-proxy process running on that same Pi, which in turn proxies through to the Docker container’s web UI.
  Why the proxy, instead of just pointing the browser straight at containerhost:8080?
  Two reasons:

1. MagicMirror sends X-Frame-Options: SAMEORIGIN, which matters if you want to wrap the feed in your own page (see #2).
2. I wanted a couple of small custom status overlays on the display itself — e.g. a banner if the Docker host becomes unreachable, or if internet connectivity drops but the local container is still fine. To overlay anything on top of MM’s own page you need it loaded same-origin, so a tiny local Node reverse-proxy on the display Pi re-serves the container’s content from localhost, strips that header, and the wrapper page around it handles the status banners.
   Why this arrangement, generally:

One MagicMirror instance/config to maintain, no matter how many physical screens you eventually want — each display Pi is just “a browser + a small proxy,” nothing module- or backend-specific.
Any hardware-specific pain (GPU driver quirks, monitor power management, etc.) on the display Pi stays isolated from the actual MagicMirror process, a crash or leak in a module’s backend logic can’t take the display down, since they’re not sharing a process tree anymore.

Honest caveat: this doesn’t make the display Pi itself lighter, it’s still a real browser doing real DOM/JS rendering and image decoding locally, so don’t expect a resource-usage miracle on the display side. What you get is architectural: single source of truth for MM itself, and a much smaller, simpler thing running on whatever hardware is stuck driving a screen
I’m pairing this with a Radar motion sensor for wake-on-motion, poll a GPIO pin and call dpms_control on on a HIGH reading, dpms_control off after N minutes of no motion. One thing worth knowing if you’re doing the same: Trixie’s kernel exposes the GPIO chip at a different base offset than older Raspberry Pi OS versions, so older libraries like onoff that write raw BCM pin numbers straight to sysfs (/sys/class/gpio/export) fail with EINVAL. Shelling out to gpioget/gpiomon from libgpiod-tools instead sidesteps that entirely: