PlatformIO Core enables telemetry by default and takes its boards from a registry

Diagnostics reporting ships enabled, and the page offers no switch

The project's own privacy note is four lines long and sits under its own heading. It asks you to share minimal diagnostics and usage information to help make PlatformIO better, and then says it is enabled by default.

That default is the whole story for a build agent. A CI container that runs pio run on every commit is a process that contacts the vendor unless somebody changes a setting, and the page carries no command line flag for it, only a documentation link: docs.platformio.org/en/latest/userguide/cmd_settings.html with the enable-telemetry anchor.

So the cost lands on whoever owns the machine: find the telemetry setting described in the linked documentation and record it in your image definition, or accept that builds report usage data.

Four of the five feature bullets point at documentation this repository does not contain

The feature list on the page reads: open source under a permissive Apache 2.0 license, a cross-platform IDE and Unified Debugger, a Static Code Analyzer and Remote Unit Testing, a multi-platform and multi-architecture build system, and a Firmware File Explorer with Memory Inspection.

Now look at where the documentation links for those go. Debugging, Static Code Analysis, and Remote Development resolve to paths under docs.platformio.org/en/latest/plus/, while Unit Testing resolves to docs.platformio.org/en/latest/advanced/unit-testing/. The same page carries a PlatformIO Labs badge pointing at piolabs.com and a Contact Us link to the same host, while the license section states that PlatformIO is Apache 2.0 for use in both commercial and personal projects.

Consequence: the bullet list is a set of pointers to documentation. Trace each bullet to its documentation page before you put it in a proposal.

setup.py asks Python for its own dependency list at build time

The packaging file does not declare dependencies. It imports them.

    install_requires=get_pip_dependencies(),
    python_requires=">=3.9",
    packages=find_packages(include=["platformio", "platformio.*"]),

get_pip_dependencies comes from platformio.dependencies, so the requirement set is computed inside the package rather than written out in the file. The practical effect is that you cannot read the dependency list by reading setup.py, and you cannot diff it in a review, because it is whatever the platformio.dependencies module returns at build time.

Two more details are worth pinning down. The floor is Python 3.9. And find_packages is restricted to platformio and platformio.*, so anything else in the tree, including the scripts/ and docs/ directories, is source-only and never ships. The console entry points both point into platformio.__main__, which is why the same tool answers to platformio and to the shorter pio. Pick one in your scripts and keep it consistent.

The udev rule ships as package data, so device access depends on your own packaging

Buried in package_data is a single system asset that decides whether you can talk to a board without root.

    package_data={
        "platformio": [
            "assets/system/99-platformio-udev.rules",
            "project/integration/tpls/*/*.tpl",
            "project/integration/tpls/*/.*.tpl",  # include hidden files
            "project/integration/tpls/*/.*/*.tpl",  # include hidden folders
            "project/integration/tpls/*/*/*.tpl",  # NetBeans
            "project/integration/tpls/*/*/*/*.tpl",  # NetBeans
        ]
    },

The file lives inside the Python package as an asset. Access to a USB serial adapter on Linux depends on a udev rule ending up in the right place and udev being told to reload, which is work your distribution's packaging or your container image has to do. On a build agent where nobody can write to the udev rules directory, uploads and serial monitoring fail in ways that look like driver problems rather than permission policy, and the fix is to install that asset deliberately rather than to debug the tool.

The template globs tell a second story. Three levels of nesting, comments naming NetBeans twice, and explicit patterns for dotfiles and hidden directories mean the package deliberately carries IDE project templates that include hidden files. An sdist assembled by a tool that drops dotfiles, or an extraction step that skips hidden folders, breaks IDE integration without breaking the build, which is a quiet failure worth checking after any packaging change.

The default pytest run excludes the example projects on purpose

The Makefile is short and it is the whole contributor toolchain.

lint:
	pylint --rcfile=./.pylintrc ./tests
	pylint --rcfile=./.pylintrc ./platformio

isort:
	isort ./platformio
	isort ./tests

format:
	black ./platformio
	black ./tests

codespell:
	codespell --skip "./build,./docs/_build" -L "AtLeast,TRE,ans,dout,homestate,ser"

test:
	pytest --verbose -n 6 --dist=loadscope tests --ignore tests/test_examples.py

before-commit: codespell isort format lint

Three things fall out of that. First, the default test target passes an explicit ignore for tests/test_examples.py, so the example projects in the repository are not exercised by the command everyone runs locally. If you change behavior that examples depend on, the suite stays green and the examples are what breaks.

Second, before-commit chains four tools in a fixed order, and codespell runs with an explicit exclusion list of words that are deliberately left uncorrected. Third, the profile target runs the CLI under cProfile with arguments passed through PIOARGS, for example make PIOARGS="boards" profile, and pipes the result into snakeviz. That last one is the fastest way to find out where your build time actually goes, and it is the only documentation of PIOARGS on this page.

Cloning gives you develop, and the release line lives in tags

The repository's default branch is develop, not main, and the contributing link points at the develop branch of a separate repository for its guidelines. So a fresh clone is the development line, which is ahead of any released version, and it is not what your users install.

The release record in the last three tags reads 6.2.0 on 2026-09-05, 6.1.19 on 2026-02-04, and 6.1.18 on 2025-03-11. Two things stand out. The 6.1.x line kept taking patch releases for close to a year between those two points, so a project that stayed on 6.1.18 was eleven months behind and still on a supported-looking branch. And 6.2.0 is recent enough that the last push on 2026-10-16 is already past it, meaning the code you would build from develop has not been through a release tag.

Consequence for your own versioning: pin to a tag, not to the branch, and decide deliberately whether a major bump is a scheduled event or something you absorb when a platform package forces your hand. The repository also ships HISTORY.rst at the top level, which is where release notes for the tags belong, and the publish target still goes through python setup.py sdist upload with no pyproject.toml in the tree, so the packaging story is a setuptools script rather than a declared build backend. Plan for the CLI version and the board platform version as two separate things that can move independently.

Libraries, boards, and toolchains are three registry object types you do not control

PlatformIO Core is the client, not the supply chain. The page points at registry.platformio.org three times, once for Libraries, once for Development Platforms, and once for Development Tools, and the links carry the t=library, t=platform, and t=tool query parameters to separate the three kinds of object.

That separation is the design and also the dependency. To compile for a board you need a development platform, which brings a toolchain, which brings the compiler and debugger you will actually invoke. None of it is in this repository, none of it is versioned here, and the page does not describe an offline mode, a vendored package directory, or a way to freeze the set you depend on. A build that worked last month can resolve differently this month because the registry moved, and the failure surfaces as a missing toolchain rather than as a dependency conflict.

So for reproducible builds the work sits outside this codebase: pin the platform and library versions in your project configuration, keep a record of what resolved, and decide what your organization does when the registry is unreachable, because the tool has no answer to that scenario on this page. Teams that need hermetic builds will be assembling that discipline themselves, and the registry is the thing they are trusting.

Editorial conclusion

PlatformIO Core suits teams that want one declarative build path across many embedded architectures, will commit to the registry for boards and toolchains, and are willing to switch off diagnostics reporting on machines that should not phone home. It suits nobody who needs a self-contained toolchain, an offline or air-gapped build, or a feature set that matches the page's bullet list exactly, since the bullets point at documentation rather than describing what is in this repository. Before adopting it, decide where your CI telemetry setting lives, pin the platform and tool versions your project needs, confirm that udev rules get installed on your Linux build agents, and run make before-commit so black, isort, pylint, and codespell agree with you.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. platformio/platformio-core on GitHub
3. Project website
4. README
5. Releases