esp-dev-kits: the documentation, schematics and factory firmware behind Espressif boards

A documentation repository, not a library

esp-dev-kits is described as Docs, Schematics, Factory Firmwares for ESP Development Kits, and the README explains what it contains: user guides, hardware resources, firmware, and demo code for development boards designed by Espressif.

The audience is stated in the overview. It provides in-depth information on selected development boards embedded with different Espressif SoCs, such as ESP32, ESP32-S2, ESP32-S3, ESP32-C3, ESP32-C5, ESP32-P4 and ESP32-S31, and the point is that you can easily get started with Espressif development boards and build your IoT applications. The README also points to the Products > DevKits page on the Espressif website for the list of all available boards, which is a useful distinction, because the repository covers selected boards and the website lists the range.

The build status badge points at the published documentation site, docs.espressif.com/projects/esp-dev-kits, and the repository itself is the source that site is built from. The docs directory, the mkdocs configuration, the.build-rules.yml and the.lbcf.yml at the top level all point to a Sphinx or MyST documentation pipeline rather than to an application.

The primary language is recorded as Python, which is the language of the build tooling in the tools directory rather than of the documentation content. The licence is Apache-2.0, with a LICENSE-APACHE file and a separate LICENSE-CC-BY-SA for the documentation text, and the last push was on 2026-10-22 with no GitHub releases published.

So the correct mental model is a hardware reference package: the manual, the board files, the factory image and the sample projects for the boards Espressif chose to document in depth.

The board matrix, split by chip family

The supported boards section is organised by SoC generation, and the order of the list is itself informative, because the newest families appear first.

The ESP32-S31 section comes first, with three boards. The ESP32-S31-Function-CoreBoard-1 is based on the ESP32-S31-WROOM-3 module and supports Wi-Fi 6, IEEE 802.15.4, Bluetooth 5.4 with LE plus BR/EDR, and Gigabit Ethernet, with an onboard microphone and speaker output, all key GPIOs routed out, and out-of-the-box AI voice interaction evaluation. The ESP32-S31-Korvo-1 is a multimedia board for smart audio and HMI applications with a dual-microphone array, speaker output and a microSD card slot, supporting speech recognition and voice wake-up, and able to connect a 4.3-inch LCD subboard and a DVP camera. ESP-Mosaico is an expandable smart interaction kit with a 480 by 480 QSPI square touch display, an audio codec and amplifier, a 6-axis IMU, dual magnetometers, SPI NAND flash, and left and right module headers for magnetic expansion.

The ESP32-P4 section follows, with the ESP32-P4X-Function-EV-Board, the ESP32-P4X-C5-Function-EV-Board and the ESP32-P4-EYE. The first two are described as multimedia development boards based on the ESP32-P4 chip with a dual-core RISC-V processor and up to 32 MB PSRAM, supporting USB 2.0, MIPI-CSI/DSI and an H264 encoder, and the two differ in the module fitted, with the C6-MINI-1 in one and the C5-MINI-1 in the other. The ESP32-P4-EYE is a vision development board with the ESP32-P4 microcontroller and an ESP32-C6 wireless module, supporting MIPI-CSI camera interface and USB 2.0 High-Speed device mode, and coming with integrated camera, display, microphone and MicroSD card expansion.

The examples directory names thirteen boards across the older families too, including the esp32-s2-hmi-devkit-1, the esp32-s2-kaluga-1, the esp32-s2-touch-devkit-1, the esp32-s3-lcd-ev-board, the esp32-s3-usb-bridge, the esp32-s3-usb-otg, the esp32-c3-lcdkit and the esp32-p4-function-ev-board, along with product-like kits such as esp-dualkey, esp-sensairshuttle, esp-vocat and the esp32-p4-eye. That spread is the real catalogue of what this repository documents in depth, and it is much wider than the three families in the visible part of the table.

Why ESP-IDF has to be set up first

The Quick Start section contains one instruction, and it is a prerequisite rather than a step.

esp-dev-kits is developed based on ESP-IDF functions and tools, so the ESP-IDF development environment must be set up first. The README then lists the Get Started documentation for each SoC it covers, with separate pages for ESP32, ESP32-S2, ESP32-S3, ESP32-C3, ESP32-C5, ESP32-P4 and ESP32-S31, and it addresses a first-time ESP-IDF user directly: if this is your first exposure to ESP-IDF, proceed to that documentation.

That is an honest and useful statement of where the real work lives. The firmware in this repository is built with the ESP-IDF toolchain, the demo code is ESP-IDF example code, and the factory images are produced by the same build system. So a developer who wants to run the demos needs ESP-IDF installed regardless, and the value of esp-dev-kits is what sits on top of it rather than a replacement for it.

The consequence for a team is straightforward. The board documentation is the part that tells you which pins are exposed, what the flash and PSRAM configuration is, what the current draw is, and which demo to flash, and the ESP-IDF setup is the part that lets you build. Installing ESP-IDF is the one-time cost, and it is the reason the README spends its only Quick Start paragraph on it.

The other detail worth noticing is the Chinese README. The repository ships README_CN.md alongside README.md, and the contributing documentation is doubled with CONTRIBUTING_CN.md, so the project is maintained for a Chinese speaking audience as well, which is consistent with where the hardware is designed and manufactured.

The board files, the CI and the pre-commit checks

The top level of the repository is the interesting part for anyone thinking about contributing, because it shows the machinery behind the documentation.

There are two licence files, LICENSE-APACHE and LICENSE-CC-BY-SA, which is the usual split for a project where the software and the prose are under different terms. There is a check_copyright_config.yaml, which suggests headers are checked on files. There is a post-mr-note.py script, a small tool that appears to post a note after a merge request, and a .pre-commit-config.yaml for local checks. The CI setup is unusual in that there are two of them, a .github directory and a .gitlab-ci.yml alongside a .gitlab directory, so the project is built and checked in both GitHub Actions and GitLab CI. There is a .codespellrc for spell checking, and a .gitmodules file, so at least one piece of the tree is a submodule.

That combination, pre-commit, two CI systems, a codespell configuration and a copyright check, tells you something about how the project treats its own consistency. For a repository whose output is documentation that people follow literally when wiring a board, a broken pin table or a stale screenshot is a real defect, and the tooling is set up to catch the mechanical class of those.

The docs directory is where the per-board content lives, and the .build-rules.yml and .lbcf.yml files at the top level are the build configuration for the site. The docs site is what the badge points to, and it is where the per-SoC structure mirrors the board tables, with a page per board under a directory named after the SoC.

Where this repository stops and the other Espressif repositories begin

Two boundaries are worth stating, and the alternative in each case is not another vendor's product but a sibling repository.

The first is the boundary with ESP-IDF itself. Everything here is built on ESP-IDF functions and tools, so if your question is how to configure a partition table, how to use a peripheral, or how to set up a project, the answer is in the ESP-IDF documentation, not here. esp-dev-kits starts where the board is concerned. That means the user guide, the hardware resources, the factory firmware for that specific board, and the demo code for it.

The second is the boundary with the documentation site as a published artefact. The site at docs.espressif.com is the same content, rendered, and the repository is the upstream. A developer who wants to file an issue or a correction about a page does it in the repository, and a developer who wants to read a page reads the site. the site carries the end user documentation and the repository carries the correction workflow.

The practical third point is about coverage. The README says selected development boards, and the visible tables cover the newest families first. A developer working on an older ESP32 board will find an example and a user guide, but not the same depth of in-depth information that a board with a dedicated function evaluation board, a sub-board connector and an AI voice interaction story has. The same is true of a board Espressif did not design, where the vendor's own documentation is the only source.

So the honest framing is that esp-dev-kits is the reference for Espressif's own evaluation boards, published as documentation with the firmware and demos attached, and a developer building a product on a custom board will use it for reference reading rather than as a starting point.

Editorial conclusion

esp-dev-kits fits a developer who has chosen a specific Espressif board and wants the user guide, the hardware details, the factory firmware and the demo code in one place rather than assembled from a product page, a datasheet and a forum thread. It does not fit someone looking for a driver library, an SDK or a build system, because all of that lives in ESP-IDF. Before starting, set up the ESP-IDF development environment, which the README makes a prerequisite, and read the per-board page for your SoC rather than the overview, since the board matrix in the README is split by chip family and the ESP32-S31 and ESP32-P4 sections come first.

Frequently asked questions

Official sources

1. espressif/esp-dev-kits on GitHub
2. Issues
3. License: Apache-2.0
4. README