Roadmap

Remappr is a universal keyboard manager: one app to connect, remap, light up, and build keyboards — across firmwares. Today it speaks ZMK, QMK, VIA, Vial and Keychron; the architecture is deliberately pluggable so more firmwares can join (see Future firmwares).

Status: ✅ Done 🚧 In Progress 🗓️ Planned 🔮 Future

Two surfaces

Remappr has a live editor (edit a connected board over the ZMK Studio / VIA protocol) and a builder + config compiler (design a board and export firmware project files). A feature can be done on one and not the other — ZMK's compile-time behaviors (combos, macros, tap-dance, encoders) are fully authored in the builder/compiler but cannot be edited live on a board, by protocol design.

At a glance

Area	Status
Keyboard Builder	✅ Done	Design a board end-to-end
Config & compilers	✅ Done	One config → 4 firmwares
Editor tools	✅ Done	Heatmap, key test, RGB paint
Live editing — ZMK	✅ Core	Narrow by protocol
Live editing — QMK/Vial/Keychron	✅ Broad	Rich VIA/Vial surface
Build & flash pipeline	🚧 Partial	Cloud build works; flasher planned
Future firmwares	🔮 Future	First-party Remappr Firmware

Firmware support matrix

Firmware	Live editor	Builder / export	Status
ZMK (wireless, BLE)	✅	✅	Supported
QMK	✅	✅	Supported
VIA	✅	✅	Supported
Vial	✅	✅	Supported
Keychron	✅	✅	Supported
Remappr Firmware (first-party) ✨	—	—	🔮 Future

More firmwares can be added over time — the adapter + compiler architecture is built for it. None besides Remappr Firmware are on the plan today.

---

Keyboard Builder

The builder is feature-complete for designing a board.

Feature	Status
Full-screen shell (toolbar · panels · canvas · inspector)	✅
Start from preset · KLE import · ortho grid · blank	✅
Layout editing — drag / resize / rotate, snap & free-form	✅
Matrix wiring — per-key row/col, overlay, pin labels, auto	✅
Layers — add / duplicate / delete / rename / reorder	✅
Firmware-aware binding picker	✅
Identity & hardware form	✅
Lighting — underglow + backlight	✅
Encoders & analog sliders	✅
Layout variants / VIA layout options	✅
Save to / load from a keyboard library	✅
JSON config panel (Monaco + schema)	✅
Export & build modal	✅
Guided coachmark tour	✅

Config & multi-firmware compilers

The generalized config and compilers.

Feature	Status
Firmware-agnostic keymap config	✅
Normalize / serialize round-trip	✅
Zod validation + generated JSON Schema	✅
ZMK compiler — .keymap + .overlay, split	✅
QMK compiler — keymap.c + keyboard.json	✅
VIA definition · Vial definition (UID + unlock)	✅
Project bundle — repo + GitHub Actions + README	✅
Capability gating · readiness · pin maps	✅
QMK C-scaffolding for combos / macros / tap-dance	🗓️

INFO

The QMK family currently emits warnings + KC_NO placeholders for combos, macros and tap-dance in keymap.c — those behaviors are fully supported on ZMK export and on live Vial. Generating the C scaffolding is the open item.

Build & flash pipeline

Stage	Status
Cloud build — export a ready-to-push project; GitHub Actions builds the artifact	✅
One-click GitHub build (REST client + artifact proxy exist; not yet wired to UI)	🚧
In-app flasher (UF2 / DFU)	🗓️
In-app local toolchain build	🗓️

ZMK live editor

Feature	Status
Real-time keymap changes (no reflash)	✅
USB/serial (CDC-ACM) + BLE (BlueZ) transports	✅
Key / behavior assignment	✅
Physical-layout selection · layer rename / add / reorder / count	✅
Device lock / unlock (state observed; unlock by combo)	✅
Basic hold-tap property config	🚧
Live tap-dance/macro steps · live combos · live conditional layers	🗓️
Live encoder assignment · host-locale · devicetree import round-trip	🗓️
New behavior / new layout creation on a live device	🔮

All ZMK bindings (key/layer/output/lighting/power/mouse) and composite behaviors (hold-tap, tap-dance, macros, mod-morph, sensor-rotation) are

✅ in the builder + compiler — see

Actions. Live on-device editing of compile-time behaviors is limited by the ZMK Studio protocol.

QMK / VIA / Vial / Keychron live editor

Feature	Status
Raw-HID / VIA transport · layout sideload	✅
Key / layer / modifier / media assignment · layer switching · one-shot mods	✅
Mouse keys (movement / buttons / wheel)	✅
Vial: tap-dance · combos · key overrides · macros · encoders · alt-repeat · lock	✅
VIA RGB underglow effect + color	✅
Keychron: per-key RGB · mixed-region RGB · wireless (LPM/NKRO/factory)	✅
Keychron: dynamic debounce / report-rate / snap-click	✅
Bootmagic · full EEPROM reset · QMK Settings panel	🗓️
Backlight-brightness · Auto-Shift · Caps-Word · One-Shot config panels	🗓️

Editor tools

Feature	Status
Heatmap · live view · key test (HW matrix + OS fallback)	✅
Per-key RGB painting (Keychron / per-key QMK)	✅
Typing load stats · wireless & advanced settings panels	✅
Undo / redo · save / discard pending changes	✅

App-level

Feature	Status
Electron shell	✅
Firmware adapter abstraction (plug-in per vendor)	✅
Capability-gated UI	✅
Keymap import / export (Remappr JSON config)	✅
Cloud sync / backup · profile sharing	🗓️

---

Future firmwares

✨ The north star: Remappr Firmware

The long-term vision is a first-party Remappr Firmware — a native firmware the manager controls end-to-end. Third-party protocols cap what can be edited live (ZMK Studio can't author combos, macros, tap-dance, encoders or new behaviors on a connected board; VIA/Vial vary by build). A firmware designed alongside the app removes that ceiling: everything you can design in the builder becomes editable on the device in real time, from one config. Until then, every feature lands on the firmwares below.

🔮 Future — early vision, no ship date yet.

Remappr's goal is to be firmware-agnostic. Two extension points make new firmwares tractable:

• A firmware adapter for the live surface — probe a connected device, expose a KeyboardService with capability-gated facades. The UI adapts automatically.
• A compiler Strategy for the export surface — lower the generalized config to that firmware's project files, registered in the capability matrix.

On the plan:

Firmware	Notes	Status
Remappr Firmware ✨	First-party firmware — full live control, no protocol ceiling	🔮 Future

No other firmwares are planned right now — but thanks to those two extension points, new ones (a CircuitPython firmware, a vendor's VIA/Vial channels, bare HID, …) can be added if demand appears. Want to add one? See Adding a firmware target.

---

The authoritative, per-behavior status table also lives in the project README.