Betaflight: Open Source Flight Controller Firmware

What Betaflight actually is, and who the repository is for

Betaflight is flight controller software, described in the README as free, open-source flight control software for every kind of drone, from racing and freestyle to cinematic filming, long range, micros and wings. 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's Hardware Issues section says the Betaflight team fixes Betaflight while manufacturers support their hardware, so the project sits between board vendors and pilots rather than in front of them.

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.

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.

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's Hardware Issues section says the Betaflight team fixes bugs in the firmware, the Betaflight App and the cloud build, while manufacturers support their hardware, so 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 targets for STM32 F4, F7, G4, H5 and H7 (plus C5 and N6 in developer preview), AT32F435, APM32 and RP2350 processors, with experimental ESP32 and X32 support, and points to the hardware policy for current status. Boards on processors outside that list may not be supported, so 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 the Betaflight App into 21 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 is not fully consistent: the README text says App, while its issue tracker and Crowdin links still use the betaflight-configurator name. 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,, but the README makes no comparison with it.

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. 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. 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-11-02. 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 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 says manufacturers support their hardware. 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