Lunar: DDC/CI Brightness Control for External Monitors on macOS

What Lunar fixes for macOS users with external displays

macOS controls the brightness of the built-in display and of Apple's own XDR and HDR panels, but it has no equivalent control for a third-party monitor plugged in over HDMI or DisplayPort. The monitor's own buttons are the fallback, and they are slow to reach and inconsistent between vendors. Lunar is an app for that gap: it drives the monitor's hardware brightness through the DDC protocol, and the README states plainly that it does not use a software overlay if the monitor supports DDC/CI. That distinction matters. An overlay dims the image by compositing a translucent layer, which reduces contrast and can wash out dark content; changing the backlight changes the panel itself. Lunar also covers volume, contrast and input switching, and it adds keyboard control, hotkeys and app-specific presets on top. The audience is narrow and specific: people on macOS, with at least one external display, who care enough about brightness to want it on a key rather than a button on the bezel.

How DDC/CI control actually works in Lunar

The mechanism is DDC/CI, the Display Data Channel Command Interface that lets a host send control messages to a monitor over the video cable. Lunar sends those messages to set brightness, and the README lists the connection types it has been tested with: HDMI 1.0 through 2.1, DisplayPort 1.0 through 2.0, Thunderbolt 4 and 3 over USB Type-C, Thunderbolt 2 over mini DisplayPort, VGA, DVI, and adapters that forward DDC messages properly. That last item is the weak link in the chain and worth reading twice, because the app's behaviour depends on hardware it does not control. The adaptive brightness features layer on top of the same control path. There are three sources: an external light sensor, the built-in light sensor of a MacBook or iMac, and sunrise and sunset times for your location. Whichever source is selected, the result is written to the monitor as a DDC brightness value, not as a display filter. Lunar also respects per-monitor minimum and maximum values for the keyboard and hotkey controls, which is a small detail that prevents a hotkey from pushing a panel past what it can accept. The README notes that Lunar does not interfere with the native adaptive brightness macOS applies to the built-in display, and that it works alongside Night Shift and True Tone, and alongside f.lux as long as Gamma dimming is not used. That last constraint is the honest kind of interoperability note: two tools that both modify the image will fight each other.

Installing Lunar and setting up a first monitor

There are two installation paths, both from the README. The first is a direct download of Lunar.dmg from lunar.fyi. The second is Homebrew:

brew install --cask lunar

That command installs the cask named lunar. After it finishes, Lunar appears in Applications, and the README's screenshots show the app living in the menu bar, with a QuickActions menu, a Display page, a Display Settings page, a Built-in Display page, an Input Hotkeys page, a Configuration page and a Hotkeys page. For a first real use, open the menu bar item with an external monitor connected and check whether the app can read and write brightness on that display. If it can, the hardware path is working and the rest of the features are available. If it cannot, the problem is almost always the cable or an adapter that does not forward DDC messages, not the app. Once brightness responds, the next thing worth configuring is a hotkey, because that is the feature that replaces the monitor's physical buttons. The README also documents screen orientation hotkeys, Ctrl+0, Ctrl+9, Ctrl+8 and Ctrl+7 mapped to 0, 90, 180 and 270 degrees for the display the cursor is on, and up to three input-specific hotkeys for switching sources. Adaptive brightness is a separate configuration step, and the README points to three options: an external light sensor, the built-in sensor on a MacBook or iMac, or location-based sunrise and sunset times.

The repository cannot be built, and that is a real limitation

The README says it directly: Lunar cannot be built from this repo because the source code for the paid features is hidden. The contributing section goes further, stating that contributions are paused because Lunar has paid features and the Pro features code is encrypted. The repository layout supports this: there is a .gitsecret directory and an install-git-secret target in the Makefile, so parts of the tree are encrypted at rest. For an engineer evaluating adoption, this changes the calculus. The MIT licence covers what is published, but a meaningful part of the shipped application is not in the tree, so you cannot read it, patch it, or reproduce the binary from source. If your organisation requires that every binary on a managed Mac be buildable from audited source, Lunar fails that test before any feature discussion starts. The Makefile also shows a release pipeline that expects tooling most readers will not have: swiftformat, sourcery and git-secret are installed through Homebrew by the install-deps target, and the version is extracted from the Xcode project's MARKETING_VERSION. This is a developer's build system for the maintainer, not a documented contributor workflow. The README does not describe a rollback path if a monitor stops responding after a DDC write, and it does not list monitors known not to work.

Where Lunar is the wrong tool, and what to use instead

Lunar is macOS only. Its language is Swift and its features are built around macOS APIs, the menu bar, and Apple's display stack, so if your fleet is Linux or Windows, this project is not a candidate at all. The second case is a monitor that does not implement DDC/CI, or a KVM or adapter that strips the messages. Lunar's own README concedes that it relies on adapters that forward DDC messages properly, and a software overlay is exactly what it declines to fall back to. For those setups, a tool that dims in software is the honest alternative, and f.lux is the one the README itself names, with the caveat that Lunar works alongside it only if Gamma dimming is not used. The difference in approach is fundamental: a gamma or overlay dimmer changes the pixel values the GPU sends and works on any display, including ones with no DDC support, at the cost of contrast and colour accuracy. Lunar changes the backlight and keeps the signal intact, at the cost of depending on hardware cooperation. If you need brightness control to work identically across a mixed fleet of monitors, including cheap panels and KVM switches, the software approach is more predictable. If you want the panel itself to change, Lunar is the one making that bet.

Maintenance, releases and what the MIT licence does and does not cover

The repository is not archived, and the last push was on 2026-07-14, the same day as the v6.11.0 release. The two releases before that were v6.10.4 on 2026-05-25 and v6.10.3 on 2026-05-14, so the cadence over that window is roughly monthly, with the caveat that a release date is not a promise about the next one. The CHANGELOG.md in the repository is generated from the ReleaseNotes directory by a Makefile target, which means the changelog and the release notes are the same content in two places, and the release notes are the place to look for behaviour changes between versions. Upgrade cost is low for users: the Homebrew cask tracks the app, and the dmg download is the same artifact. The licence is MIT, which permits use, modification and redistribution of the published source. It does not change the fact that the paid features are encrypted and absent, so the licence grants rights over code you can see, not over the whole application. This is not legal advice; if the distinction between the published source and the shipped binary matters to your compliance process, that is a question for whoever owns that process.

Editorial conclusion

Lunar is worth adopting if you use macOS with external monitors and want hardware brightness, volume, contrast and input switching from the keyboard and menu bar. It is the wrong choice if you need to build from source, audit the whole codebase, or run it on Linux or Windows, since the repository states it cannot be built and the paid features are encrypted. Before installing, check that your monitor and cable forward DDC/CI messages, because that is what the app depends on.

Frequently asked questions

Official sources

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