Betaflight: Flight Controller Firmware for Multi-Rotor and Fixed Wing Craft

What Betaflight actually is, and who the repository is for

Betaflight is flight controller software, described in the README as firmware used to fly multi-rotor craft and fixed wing craft. It is not a desktop application and not a configuration tool. The repository at betaflight/betaflight is the firmware itself, written in C, licensed GPL-3.0, with the default branch named master. Configuration happens elsewhere, through the Betaflight App at app.betaflight.com, which the README calls a progressive web app so it should always be the latest version.

That split matters when you decide whether to clone this repository. If your goal is to fly a quadcopter, you almost certainly do not need the source at all. You need a supported flight controller, the app, and a target build that already exists. The repository is for people who build firmware images, add or modify target configurations, or contribute code and translations. The README states plainly that Betaflight does not manufacture or distribute its own hardware, so the project sits between board vendors and pilots rather than in front of them.

The README frames the project's priorities as flight performance, leading-edge feature additions, and wide target support. Those three goals pull against each other, and the target support requirement is the one that generates the most process: the README points to a separate page on betaflight.com listing the requirements for pull requests that add new targets or modify existing ones. If you maintain a board definition, that page is your contract, not the README.

How the firmware is structured: targets, the Makefile, and the devcontainer

The build is driven by a Makefile at the repository root. It exposes TARGET and CONFIG as the two variables a user is expected to override on the command line, along with compile-time options such as OPTIONS, EXST, RAM_BASED, CUSTOM_DEFAULTS_EXTENDED, DEBUG and DEBUG_HARDFAULTS. Running make help lists the supported targets, according to the comment at the top of the file.

A few of those variables encode real hardware constraints rather than build preferences. FLASH_SIZE is documented in the Makefile as an override for low-end chips that actually have more flash than advertised, which tells you the firmware is sensitive to flash capacity on some boards. EXST compiles for external storage bootloader support, and RAM_BASED compiles a target to be loaded into RAM. The Makefile also sets SERIAL_DEVICE by globbing /dev/ttyACM* and then /dev/ttyUSB*, falling back to the literal string no-port-found, which is how flashing finds a board on Linux and macOS.

The source tree is organised under src/, with lib/ for dependencies and mk/ for included make fragments. The repository also carries a .devcontainer directory, and the README recommends that route explicitly for Windows developers, describing it as a consistent build environment across all platforms. For anyone who has fought a cross-compilation toolchain on Windows, that recommendation is the most practically useful sentence in the README.

Installing and building a first firmware image

The README does not give a native install path. It points to https://betaflight.com/docs/wiki for installation and documentation, so the wiki is the authoritative source for flashing a board and for toolchain setup outside the container. What the README does give is a container-based build, and the commands below are copied from it.

The first command builds the development image from the containerfile inside the .devcontainer directory, tagging it betaflight-dev. The second runs that image with the current working directory mounted at /workspace and builds a target named SPEEDYBEEF405WING.

docker build -t betaflight-dev -f .devcontainer/containerfile .devcontainer/
docker run --rm -v "${PWD}:/workspace" -w /workspace betaflight-dev make TARGET=SPEEDYBEEF405WING

SPEEDYBEEF405WING is the example target the README uses. Substitute the target name for your own board, and confirm it exists by running make help, which the Makefile comment says lists the supported targets. If the target name is wrong, the build fails rather than producing a generic image, because target selection is what pulls in the board's pin mapping and peripheral configuration.

For VS Code users the README describes a second route: install the Dev Containers extension, open the folder, and select Reopen in Container. The devcontainer documentation is linked from the README and covers hardware flashing, which the README does not walk through itself.

make help

The variable defaults in the Makefile are worth reading before your first build. RAM_BASED and EXST default to no, CUSTOM_DEFAULTS_EXTENDED defaults to no, and DEBUG is empty, which the Makefile describes as an ordinary build with all optimizations enabled. The Makefile warns that releases should not be built with DEBUG_HARDFAULTS because that flag does not disable PWM output.

Where Betaflight stops being the right tool

The clearest boundary is hardware support. The README states that Betaflight does not manufacture or distribute its own hardware, and the section on hardware issues is cut off mid-sentence in the repository README, but the intent is unambiguous: board-level faults are the vendor's problem, not the firmware project's. If you bought a flight controller that ships with a closed firmware stack and a vendor configuration utility, Betaflight will not adopt it for you. You need a target definition that exists, and adding one is a reviewed pull request against documented requirements, not a local config file.

Processor support is the second boundary. The README lists STM32 F4, G4, F7 and H7 as the supported families. Older STM32 F3 and F1 boards are not in that list, which means a large back catalogue of flight controllers cannot run current Betaflight. If you are repairing an older craft, check the processor before assuming the firmware will flash.

Third, the release cadence is published outside the repository. The README sends readers to betaflight.com for the release schedule and the development cadence, and notes a calendar versioning change. The recent release tags follow a year-dot-minor-dot-patch pattern, with 2026.6.0-rc3, 2026.6.1 and 2026.6.2 appearing in sequence. Anyone pinning a fleet to a specific firmware version should read the release notes for that version rather than assuming behaviour is stable across the calendar boundary.

Finally, the README's own feature list is broad but not a compatibility promise. DShot at 150, 300 and 600, Multishot, Oneshot at 125 and 42, and Proshot1000 are all listed as supported motor protocols, but which ones your ESC and target combination accepts is a hardware question the README does not answer.

Betaflight Configurator, the Betaflight App, and what changed

The most common point of confusion for new users is the difference between the firmware repository and the configuration tool. The README directs configuration to the Betaflight App at app.betaflight.com and describes it as a progressive web app. The repository's contributing section, however, still points bug reports at github.com/betaflight/betaflight-configurator, and the translators section describes maintaining translations for Betaflight Configurator into 21 named languages, including Català, Dansk, Deutsch, Español, Euskera, Français, Galego, Hrvatski, Bahasa Indonesia, Italiano, 日本語, 한국어, Latviešu, Português, Português Brasileiro, polski, Русский язык, Svenska, 简体中文 and 繁體中文.

So the naming in the repository is not fully consistent: the README's installation-facing text says App, while the contributor-facing text says Configurator. Translation work is coordinated on Crowdin at crowdin.com/project/betaflight-configurator, and the README asks would-be translators to join the translation channel on the project's Discord server. If you want to improve a translation, that is the documented route, and it is a genuinely low-barrier way to contribute compared with firmware changes, which the README says go through a thorough review process and require you to explain what you want to achieve.

The practical consequence for a pilot is that you configure through the browser and do not need to install a desktop client, and that the app updates itself by virtue of being served from the web. The practical consequence for a contributor is that firmware, app and translations live in different places with different review cultures.

Alternatives and how the approach differs

The obvious alternative in the same lineage is Cleanflight, which appears in this repository's topic list alongside betaflight, flight-controller and hacktoberfest. The topic tag is the only reference to it in the README, so treat the relationship as historical rather than as an active comparison the README makes.

The more useful contrast is architectural rather than project-to-project. Betaflight's model is a single firmware codebase compiled per target, with configuration layered on top through a web app and, for deeper changes, through a command-line interface the README lists among the features via in-flight manual PID tuning and rate adjustment. A closed vendor firmware typically inverts this: the board ships with one image, the configuration utility is tied to that vendor, and you cannot build a different image for the same hardware. The trade-off is that Betaflight gives you the source and the target system, and in exchange you accept that a target must exist for your board and that no vendor will support a custom build.

Within Betaflight itself, the meaningful choice is not which firmware but which build options. CUSTOM_DEFAULTS_EXTENDED reserves space for custom defaults, which is how a board vendor ships sensible starting values. RAM_BASED changes how the image is loaded. EXST changes bootloader expectations. Those are the levers that distinguish one Betaflight build from another on the same silicon, and they are set at compile time, not in the app.

Licence, maintenance and what upgrading costs

Betaflight is licensed GPL-3.0, and the repository carries both a LICENSE file and a DEFAULT_LICENSE.md. The Makefile itself opens with a Beer-Ware licence notice attributed to [email protected] covering that file. The practical reading is that distributing a modified firmware image carries source obligations under GPL-3.0, while the build script carries a permissive notice of its own. If you plan to ship hardware with a modified Betaflight build, that combination is worth putting in front of someone qualified to assess it; nothing here is legal advice.

The repository is not archived, and the last push was on 2026-09-19. Releases 2026.6.0-rc3, 2026.6.1 and 2026.6.2 landed between 2026-07-23 and 2026-09-16, and the README states that the release schedule and development cadence are published at betaflight.com. That is a calendar-versioned cadence, so upgrade cost is best estimated by reading the notes for each release you skip rather than by assuming patch releases are inert.

For a builder, the upgrade cost has two parts. Rebuilding is cheap once the devcontainer is in place, because the same image builds any target. Re-validating is not: target definitions, build flags and defaults can change between releases, and the target submission requirements on betaflight.com are the document that governs whether your target definition still conforms. Budget for a rebuild-and-refly cycle per release, not just a rebuild.

Editorial conclusion

Adopt Betaflight if you fly multi-rotor or fixed wing craft built around a supported STM32 target and you want to tune PIDs, filters and rates yourself. Do not adopt it expecting vendor support for a specific board, because the README states Betaflight does not manufacture or distribute hardware, and hardware issues belong to the board maker. Before flashing anything, confirm your exact target name appears in the build system, check the target requirements page on betaflight.com if you maintain a board definition, and read the versioned release notes for the release you intend to flash rather than assuming behaviour carried over from an earlier one.

Frequently asked questions

Official sources

1. betaflight/betaflight on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases