choose your QMK keyboard source folder, keep its default keymap or import your own keymap.json, select the lighting channels QMK actually declares, and save a firmware file for your normal flashing tool.
keyflare never guesses where LEDs are installed. if QMK only declares a Scroll Lock indicator, Scroll Lock is the only channel you can select. the physical LED decides the color.
- local QMK keyboard source import, including target families with revisions
- default QMK keymaps or imported
keymap.jsonfiles for the same target - read-only keyboard geometry from QMK layout metadata
- RGB Matrix reactive effect while keys are held, plus standard backlight, Num Lock, Caps Lock, Scroll Lock, Compose, and Kana channels
.hex,.bin, and.uf2output through the real QMK compiler- isolated Electron renderer with a small validated IPC surface
- no per-key LED guesses, or built-in flashing
keyboard source + keymap + selected declared channels
|
v
keyflare desktop app
- reads QMK metadata
- shows keyboard geometry
- adds keyflare/reactive
|
v
pinned qmk_firmware
|
qmk compile
|
v
.hex / .bin / .uf2
|
v
your usual flashing tool
the generated QMK module counts held physical keys. it turns the selected channels on after the first press, then restores the existing backlight or host indicator state after the last release.
the preview highlights every key for backlight and the matching logical lock key for an indicator. this feedback explains the selected channel. it does not claim that the indicator LED is physically installed under that key. the RGB Matrix channel runs QMK's typing heatmap effect while at least one key is held, then restores the user's saved effect and on/off state without EEPROM writes.
- install QMK's supported build environment for your operating system.
- open keyflare and let it download the pinned QMK source on first launch.
- choose the QMK keyboard source folder you intend to build. if it contains several revisions, choose the exact target from the aligned variant menu.
- use the default keymap or import a matching QMK
keymap.json. - select one or more declared reactive channels.
- build and save the firmware artifact.
- flash it with QMK Toolbox, QMK CLI, or your usual bootloader-specific tool.
keyflare compiles firmware. it does not put a keyboard into bootloader mode, install drivers, or flash the device for you.
| QMK metadata | keyflare behavior |
|---|---|
| standard backlight feature with a declared pin | offer the keyboard backlight |
| standard lock or host indicator pin | offer that exact indicator |
| RGB matrix with a declared driver or WS2812 pin, and a LED map | offer a reactive RGB Matrix channel |
| Caps or Scroll Lock on an RGB Matrix target with a LED map, without a pin | offer an RGB indicator on a LED you pick from the map |
| RGB matrix without a LED map | explain that the target needs rgb_matrix.leds |
| no supported declared channel | explain that the target cannot be configured |
this is deliberately strict. a keyboard photo, layout shape, compiled firmware file, or model name is not enough evidence to infer physical LED wiring.
the reactive RGB Matrix channel also requires the target's metadata to define its LED map (rgb_matrix.leds), because QMK's build cannot address the LEDs without it.
keyflare uses QMK's supported host environment instead of bundling several gigabytes of compilers and device tools.
- Windows: install QMK MSYS. keyflare detects
C:\QMK_MSYSautomatically, or lets you choose theQMK_MSYSfolder when it is installed elsewhere. - macOS: install QMK with Homebrew and complete
qmk setup. - Linux: install QMK CLI and run the QMK bootstrap setup for your distribution.
run qmk doctor if setup fails. keyflare accepts QMK's minor-warning status because missing flashing rules do not block compilation, but it stops on major toolchain errors.
the managed build core is pinned to vial-qmk dd43959ae5c08d8a28d38a1acf7b04e86b14a344. a keyboard folder is not a complete compiler, so keyflare keeps the build system in a sparse checkout that excludes the upstream keyboard catalog. users import only the keyboard source they want to build. if that source ships a keymaps/vial folder, keyflare can compile it as Vial firmware for vial.rocks.
keyflare uses Bun, React, Electron, and electron-vite.
bun install
bun run devrun the complete local verification suite:
bun run verify
bun run format:checkcreate an unpacked build for the current platform:
bun run packagethe release workflow builds unsigned Windows x64, macOS x64/ARM64, and Linux x64 artifacts when a v* tag is pushed.
src/rendererowns the VIA-inspired interface and has no Node.js access.src/preloadexposes fixed operations through Electron's context bridge.src/main/index.tsaccepts dialogs only from the active trusted window.src/main/app-service.tsowns selected-source and selected-keymap paths, compilation requests, and artifact saving.src/main/firmware-build.tsvalidates QMK, imports one keyboard family into the managed checkout, and runs each compilation in an isolated temporary userspace.src/sharedcontains the validated IPC and QMK metadata contracts.resources/qmk-module/keyflare/reactivecontains the QMK Community Module copied into each managed build.
the Electron window uses context isolation, renderer sandboxing, no Node.js integration, schema-validated IPC inputs, and denied child windows. imported source paths never become renderer-controlled build input.
the desktop application is available under the MIT License.
the generated QMK Community Module is available under GPL-2.0-or-later, matching its QMK integration boundary.
the interface takes product inspiration from VIA, but uses original code, layout, styling, and assets.