Monarch detaches a Windows display in software and rolls back when it goes wrong

What the tool actually does to your displays

Monarch detaches, restores and switches monitor layouts without touching cables, and the README lists the capabilities in a way that is worth reading literally rather than as marketing.

You can detach a monitor in software, with no cable unplugging, and reattach it later. You can edit resolution, fractional refresh, orientation, HDR and supported scaling. You can extend, duplicate or detach displays, including a duplicated pair sitting beside an extended monitor. You can save display layouts with an optional audio output per profile, and the current audio output is shown beside the layout preview. You can restore the previous layout quickly, apply layouts with hotkeys, and recover automatically with a confirmation timeout if a layout change goes wrong.

The mechanism is stated in one line, and it is the key to everything else: it uses the Windows display topology APIs, DisplayConfig, to change which outputs are active. So this is not a screen recorder that fakes a disconnected display, and it is not a virtual display manager. It asks Windows to change the topology, and Windows does the work, which is why the effect is the real one, including for applications that react to display changes.

The platform is Windows 10 and 11, stated on the badge in the README, and the primary language of the repository is Rust.

The layout preview and the rule that gaps must be resolved

Monarch 2.0 starts with a fresh configuration, and the README is blunt about the consequence: settings and profiles from 1.x are not supported or migrated, so you recreate profiles from your current desktop. A 2.0 release that drops the 1.x data is a reset rather than an upgrade, and anyone moving has to budget for redoing their profiles.

The layout editing model has two halves. You drag monitors in the Layout Preview to arrange them, and dropped monitors snap to an adjoining edge. Gaps and overlaps must be resolved before the Save layout button will work, and that button applies positions only. Discard changes restores the preview without touching Windows, so the preview is a staging area rather than a live view of the desktop.

Keyboard handling is described too: arrow keys move a focused monitor and Shift makes larger adjustments, which matters on a desk where a small drag of a 34 inch ultrawide moves it by an unhelpful amount.

The per-display settings live in a dialog next to each monitor's Attach and Detach button, and cover resolution, refresh rate, orientation, scaling, HDR, duplication and the primary display. Save settings applies directly from that dialog and Cancel discards the changes, and the dialog does not apply unsaved positions from the preview. Both save actions use the confirmation timer and restore the captured settings if you revert or if the timer runs out.

Duplicating displays, and the shared settings that come with it

The duplicate feature is where the interesting constraints are, and the README documents them in detail.

A Duplicate of entry mirrors the selected display's desktop. Monarch then chooses a shared resolution and scaling supported by all monitors in the group. Each monitor keeps its own refresh rate when that is supported at the shared resolution, and otherwise a supported rate is selected for that monitor. Orientation and HDR remain per monitor, and the dialog shows the shared settings and each monitor's refresh rate before you save.

If Windows rejects the combination, the README says to choose compatible settings explicitly. That is the honest shape of the problem: a duplicated pair is constrained to the intersection of what both panels support, and the app can only offer you the intersection.

The other two group modes are simpler. Extend places the member beside the remaining desktop, and Detached keeps the other group members active.

The mode lists come from Windows itself, and the README explains the resulting quirk: unsupported HDR or scaling controls say why they are unavailable, and a detached or duplicated monitor may expose only its preferred and observed modes. To see more, you extend the monitor first to enumerate the additional modes. That is a Windows behaviour surfacing through the UI, and it is the kind of detail that turns a confusing screen into an explainable one.

The confirmation timer is the safety net

Every layout change in Monarch is a change to the topology of your Windows desktop, and if it goes wrong you can end up with a display arrangement you cannot see. The rollback design is the answer to that, and it runs through the whole application rather than being one setting.

The quick start describes the flow: you open Monarch, click Detach on the display you want to turn off, and then you confirm the layout change, or it auto-rolls back. The subtitle says the same thing more generally, built for fast display switching, standby behaviour and safe rollback if something goes wrong.

Revert, timeout and restart recovery restore the captured display settings and previous playback roles, so a rollback is not only about the picture but about the audio too. The saved settings in the display dialog follow the same rule, restoring the captured settings if you revert or time out.

There is a related behaviour while the app is running. Connecting or disconnecting displays preserves the detached state of monitors already present. The example given is Virtual Desktop adding a virtual monitor, with Windows reactivating your detached physical monitors, and Monarch detaching those again while keeping the new virtual display. It waits for the connection changes to settle and automatically confirms a verified correction. The README is careful about the limit: ordinary Windows display edits remain effective, and this does not continuously enforce a profile. Restarting Monarch adopts the current layout.

Audio output is a per-profile choice with a strict verification step

The audio side is more than a dropdown, and the rules around it are specific enough to be worth reading.

The Layout Preview header shows the current Windows playback device, and you change it manually through Windows Sound settings. In Profiles, outputs are grouped into Available and Unavailable, alphabetically within each group. You choose an audio output when saving a layout, or change the output beneath an existing profile and choose Save audio, and saving does not change the active displays or the audio. A Leave unchanged option lets Windows manage the audio when the profile is applied. The output selector does not touch microphones, communications preferences, volume or per-app routing, so an application configured for a specific device may keep using it.

When you apply a profile, the order is: Monarch changes the displays first, waits up to five seconds for the selected audio endpoint, and verifies the default output before starting the confirmation. Tray, shortcut and CLI profile actions confirm automatically, so a keyboard-driven switch does not need a click.

The failure behaviour is the interesting part. Unavailable outputs are still selectable, so a detached TV can be configured in advance. If an output does not become available, the profile change is rolled back with an error, and it is never substituted by another similarly named device. If a driver reinstall changes the endpoint ID you have to select the output again. Removing the profile's audio choice stays possible when audio support is unavailable, and display-only operations remain available if the audio service fails, in which case audio cannot be captured for recovery.

Automation from the command line, and the Rust and Tauri stack behind it

The CLI exists for automation, and it is one flag. You launch Monarch and ask it to apply a specific profile immediately:

monarch-desktop.exe -profile "ProfileName"

That is what makes Monarch scriptable, and combined with the hotkey support it is how a desk setup gets switched from a keyboard shortcut or from another program.

The stack is a Rust core with a web front end, which the repository layout makes clear. There is a src-tauri directory for the Tauri side, a Cargo.toml with the Rust package definition, a src directory and web directory for the interface, and components.json which is the shadcn style component configuration. The front end is React with Tailwind CSS, Radix UI primitives, lucide-react for icons and sonner for toasts, and the build is Vite with TypeScript.

The Rust side is deliberately small in what the manifest declares, with serde and serde_json for serialisation, and a Windows-only dependency block for the win32 foundation and file system features. The primary language of the repository is Rust, and the front end is TypeScript, which is the usual Tauri split.

There is a version bump tool in the tools directory with its own tests, and the test script runs the web tests and the version bump tests with the node test runner, so the release tooling is covered rather than trusted.

Releases, packaging and the state of the project

The release history is quick and recent. The versions are v2.0.3 from 2026-10-11, v2.0.2 from 2026-10-04 and v2.0.1 from 2026-09-27, and the last push to the repository was on 2026-10-11 with the repository not archived. A 2.0 line that shipped three patch releases in a fortnight suggests a project in its first push after a major version change.

The distribution is a Windows installer, an msi, downloaded from the releases page, run, and then launched from the Start Menu or the desktop. The package manifest has separate build scripts for a local msi build and a CI one, the latter pointing at a different Tauri config file, and both pass a locked flag so the dependency versions cannot drift during a build. There is a release build and publish workflow in the GitHub actions.

The licence is MIT, with the LICENSE file at the root of the repository, and there is a CHANGELOG.md. The repository also holds a docs directory with a Windows hardware checklist for real device verification scenarios, which is the right place to look before trusting a layout change on hardware the author did not test.

The project is written in English, and the README gives no hosted site, so the releases page and the app itself are the whole distribution story.

Where Monarch is the wrong choice

The first limit is the platform, and it is absolute. Everything is built on the Windows display topology APIs, the platform badge reads Windows 10 and 11, and the Rust manifest even scopes its Windows-specific dependency block with a target configuration for windows. On macOS or Linux there is nothing here to run.

The second is the profile enforcement model. The README states plainly that this does not continuously enforce a profile, and that ordinary Windows display edits remain effective. If you want a policy that is applied every time a display is plugged in, Monarch does not do that. What it does is re-detach monitors that Windows reactivated while the app is running, which is a narrower behaviour.

The third is the dependency on what Windows reports. Mode lists come from Windows, a detached or duplicated monitor may show only its preferred and observed modes, and a duplicated group is limited to the intersection of what the panels support. The tool cannot invent a mode the hardware does not expose.

The fourth is the audio fragility. The endpoint identity can change under you when a driver is reinstalled, and an output that does not appear within five seconds causes the profile change to roll back rather than to fall back to a similar device. That is a deliberate choice, since silently substituting a device is worse than failing, but it means driver updates on a machine with saved audio profiles are an event to plan for.

The fifth is the 2.0 reset. If you were on 1.x, nothing carries over, so the first session on 2.0 is rebuilding your layouts from nothing, and the hardware checklist is the sensible starting point for verifying the combinations you care about.

Editorial conclusion

Monarch fits a Windows user with two or more displays who wants to switch between a desk setup and a TV setup without unplugging cables, and who is willing to accept that the tool only manages the layouts it has captured rather than enforcing a policy. It is the wrong tool if you are on macOS or Linux, since the whole implementation sits on the Windows display topology APIs, and the wrong tool if you need a profile applied automatically on a display change, because the README is explicit that it does not continuously enforce a profile. Before you adopt it, check three things: that your displays expose the modes you need, since the mode lists come from Windows and a detached or duplicated monitor may show only its preferred and observed modes, that you recreate your profiles from scratch, because version 2.0 does not migrate settings or profiles from 1.x, and that you understand the confirmation model, where a layout change is only kept if you confirm it in time and is otherwise rolled back. The code is MIT licensed, the current release is v2.0.3 from 2026-10-11, and the platform is Windows 10 and 11.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Nuzair46/Monarch on GitHub
4. README
5. Releases