duckyPad is a 15-key macropad whose real feature is a turing-complete macro language

The scripting engine is the product, and it is not QMK or VIA

Most programmable keyboards give you a keymap editor. duckyPad gives you a language, and the README is explicit that the custom duckyScript engine is not QMK or VIA. The reasoning is spelled out in the comparison section: QMK and VIA are described as great for regular keyboards but rather limited at input automations.

The differences that matter are specific. Macros can be much longer, with the entire Bee Movie script offered as a joke about what fits in one macro, and up to 480 macros stored across the device. The language is turing-complete, with variables, conditions, loops and function calls, and it is executed on a 32-bit bytecode VM, the DuckStack project, with scratch and non-volatile memory. There are also interactions the keyboard-firmware model does not offer: reading buttons, printing to the OLED screen and changing RGB colours.

The simplest script is a key press or a combo, written as CTRL a or CTRL +. The next step up is a multi-line macro that fills in a form.

STRING Michael Scott
TAB
STRING United States
ENTER
STRING 5705550100
TAB
STRING [email protected]
TAB

Each line is an input action, and the whole block runs from one keypress. That is the difference in kind between a macro pad and a keymap: the keymap maps a key to a fixed sequence, while a script is a program that can branch on what it reads.

The language was originally designed for the USB Rubber Ducky, which the README credits, and the same lineage explains the security profile discussed further down.

32 profiles of 15 keys, with the OLED telling you what each key does

The storage model is small and specific. You create up to 32 profiles, one for each application, and each profile holds up to 15 keys, and each key has a duckyScript assigned to it. That works out to 480 macros in total, and each macro can contain over 50,000 characters.

The OLED is what makes that arrangement usable. It displays the current profile and key names, so you know what each key does at a glance, and the spec is a 128x128, 1.3 inch panel with high contrast, true black and burn-in prevention. When a script changes state, as the maze example below does, the screen can reflect it, which is a real difference from a keymap with no output.

RGB_SET 1 128 0 255

OLED_PRINT You are in a maze
OLED_PRINT of twisty little passages

VAR choice = _READKEY

IF choice == 1
    OLED_CURSOR 0 10
    OLED_PRINT It is a dead end.
    OLED_PRINT Something moves
    OLED_PRINT behind you.
END_IF

Two things are happening in that snippet. RGB_SET changes a key's backlight, and _READKEY reads which button was pressed into a 32-bit variable, and the IF branch then prints a different message. None of that is expressible in a keymap.

The input side is equally concrete. duckyPad is compatible with Cherry MX-style mechanical switches, in 3 or 5 pin form, and it ships with blank translucent ABS R4 keycaps that you can replace. Hot-swapping uses Kailh sockets, so you can install or remove switches by hand with no soldering needed. Each key has its own RGB backlight with user-configurable colour and brightness. The connector is USB-C.

The configurator writes to the microSD card, so there is nothing to recompile

Storage is where the workflow changes shape. duckyPad keeps its scripts on a microSD card, so a profile can be moved between devices with ease, and the README lists SD card storage as the reason for fast configuration, backup and deployment, with no sketchy drivers or apps and no recompiling.

The companion app is a separate open-source project, duckyPad-Configurator, and it runs on Windows, Mac and Linux with no account and no subscription needed, and with no data collection or telemetry. That last point is worth noting for a device whose whole purpose is injecting keystrokes into whatever machine it is plugged into.

The repository itself carries the tooling for the other half of the workflow. There is a copy_sample.py script, a push.sh and a reset.sh at the root, a sample_profiles/ directory and a sample_profiles.zip archive for the pre-made profiles, a keymap_instructions.md that documents how to assign keys, and a duckyscript3_instructions.md and duckyscript3_bytecode_vm.md for the language and the VM. The sample_profiles archive is the fastest way to see what a real profile set looks like before writing your own.

Because the scripts live on a card rather than in firmware, editing a macro is a file operation. That is the real difference from a keyboard that needs a reflash, and it is why the README can say there are no proprietary drivers and that it works out of the box.

Auto-switching by active window lives in a separate repository

The idea of one profile per application only pays off if the profile actually changes when you change applications, and that part is not in this repository. Automatic profile switching based on the active window is a separate project, duckyPad-profile-autoswitcher, and the README links it as its own repository rather than describing it as a built-in feature.

That split is worth understanding before you buy, because the profiles are the core of the device and the switching is the layer that makes them useful. The duckyPad side stores and runs the scripts; something else has to notice that a different application has focus and tell the pad to switch.

The mechanism in the example script gives a hint of what is possible from inside the device itself, since a script can read a button and act on it. A script that reacts to button presses can drive a menu, as the maze example does. What the autoswitcher adds is reacting to something outside the pad, namely the window title of the foreground application.

The hardware itself is modest in order to make this work. Fifteen keys, a small display and a USB-C connector, with the storage on a card so that the same pad can hold work for several applications at once. Whether fifteen keys is enough is a personal question, and the Pro model answers it differently by adding more keys and rotary encoders.

The repository ships firmware, PCB files and a kit guide for builders

This is a product repository as much as a firmware repository, and that shapes what you can do with it. The top-level entries include a firmware/ directory and a pcb/ directory, alongside the documentation set: build_it_yourself.md, kit_assembly_guide.md, getting_started.md, starting_fresh.md, troubleshooting.md, keymap_instructions.md, firmware_updates_and_version_history.md, duckyscript_info.md and the two duckyScript 3 documents.

The separation between kit_assembly_guide.md and build_it_yourself.md is the important distinction for a reader. The kit guide covers assembling the hardware from a kit, and the build-it-yourself document covers making the thing from scratch, with the pcb/ directory holding the board files for that path. The firmware/ directory holds the C code, which is why the repository's primary language is recorded as C.

The documentation set also tells you what happens over the life of the device. firmware_updates_and_version_history.md tracks what changed and when, and starting_fresh.md presumably covers the state you want to return to when experimenting has left a mess. troubleshooting.md is there for the moments when a key stops responding or a script does not fire.

The commercial side is simple. duckyPad was funded on Kickstarter, and it is now available on the author's Tindie store, with a duckyPad Pro model that adds rotary encoders, more keys, Bluetooth, a bigger display, more script storage and an expansion module. The Pro is a different product, and it has its own documentation site.

MIT licensing, and a repository that is open but also a shop front

The licence is MIT, and the LICENSE file is at the repository root. You can use, modify and redistribute the code and the design files, including commercially, provided the copyright notice and the licence text are kept. For the firmware and the PCB files that is an unusually clean grant, and it means a fork of the firmware is a legitimate path. This is a licensing fact rather than legal advice.

The open-source claim is also stated as a feature, alongside hot-swap and per-key RGB, with no proprietary drivers and no need for a driver at all. The companion configurator is open source too, and the profile autoswitcher is a public repository.

The maintenance picture needs reading carefully, because the dates tell two different stories. The most recent tagged release is 3.1.0, published on 2025-05-02 under the name duckyPad Configurator, and the two before it are 1.6.4 from 2024-01-22 and 1.6.3 from 2023-12-02. The last push to the repository was on 2026-05-14, a year after that tag. The repository is not archived and the default branch is master.

So the code keeps changing while the releases lag. For a firmware project, the practical rule is to read firmware_updates_and_version_history.md before flashing anything, because the version history file is the artefact that tells you what changed, and the tag names in the releases list are for the configurator rather than clearly for the device firmware.

The project also has a community layer, with an official Discord for discussions, questions, script sharing and updates, and a Kickstarter backers file in the repository.

The same mechanism that fills a form can fill a form with someone else's data

It would be dishonest not to mention the other side of this device, because the README itself does. In a section labelled Hackerman it notes that by automating HID inputs you can take over an entire computer with the push of a button, and it names this as a BadUSB attack, which it identifies as the original purpose of the USB Rubber Ducky.

The mechanism is the same in both directions. A HID keyboard is a device that sends keystrokes, and the operating system trusts it, so a device that can send arbitrary keystrokes can type a command, open a terminal and run whatever is typed next. The difference between a macro pad and a malicious USB device is the intent and the context, not the physics. A script that fills in a form and a script that opens a shell look the same on the wire.

That is why the security posture of the tooling matters, and the configurator's promise of no data collection and no telemetry is relevant rather than decorative. A device that runs arbitrary code against your machine, carried on a card, should be one you can inspect. The MIT licence, the public firmware and the open configurator are what let you do that.

The real alternative, if you want input automation without that property, is the keyboard firmware path the README compares against. QMK and VIA give you layers, combos and macros in a keymap model, with the whole ecosystem built around them, and they are what you should reach for if your automation is a fixed sequence rather than a program. duckyScript is the answer when you need branching, loops, variables and a screen that shows state. The README's own summary is that QMK and VIA are great for regular keyboards but rather limited at input automations, and that duckyScript suits power users with more demanding scripting needs.

Editorial conclusion

duckyPad fits a power user who wants one physical key per macro rather than a keymap editor, who needs loops and variables that a keyboard firmware layer does not offer, and who is willing to buy the hardware rather than build it. It does not fit someone who wants to flash a keyboard with QMK or VIA, since duckyScript is explicitly not QMK or VIA, and the Pro model is a different product with Bluetooth and rotary encoders. Before buying, check the getting_started.md file and the firmware update history, and decide whether you want the 15-key duckyPad or the Pro.

Frequently asked questions

Official sources

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