cibuildwheel

Documentation

Python wheels are great. Building them across Mac, Linux, Windows, on multiple versions of Python, is not.

cibuildwheel is here to help. cibuildwheel runs on your CI server - currently it supports GitHub Actions, Azure Pipelines, Travis CI, CircleCI, and GitLab CI - and it builds and tests your wheels across all of your platforms.

What does it do?

While cibuildwheel itself requires a recent Python version to run (we support the last three releases), it can target the following versions to build wheels:

	macOS Intel	macOS Apple Silicon	Windows 64bit	Windows 32bit	Windows Arm64	manylinux musllinux x86_64	manylinux musllinux i686	manylinux musllinux aarch64	manylinux musllinux ppc64le	manylinux musllinux s390x	manylinux musllinux armv7l	iOS	Pyodide
CPython 3.8	✅	✅	✅	✅	N/A	✅	✅	✅	✅	✅	✅⁵	N/A	N/A
CPython 3.9	✅	✅	✅	✅	✅²	✅	✅	✅	✅	✅	✅⁵	N/A	N/A
CPython 3.10	✅	✅	✅	✅	✅²	✅	✅	✅	✅	✅	✅⁵	N/A	N/A
CPython 3.11	✅	✅	✅	✅	✅²	✅	✅	✅	✅	✅	✅⁵	N/A	N/A
CPython 3.12	✅	✅	✅	✅	✅²	✅	✅	✅	✅	✅	✅⁵	N/A	✅⁴
CPython 3.13³	✅	✅	✅	✅	✅²	✅	✅	✅	✅	✅	✅⁵	✅	N/A
CPython 3.14³	✅	✅	✅	✅	✅²	✅	✅	✅	✅	✅	✅⁵	✅	N/A
PyPy 3.8 v7.3	✅	✅	✅	N/A	N/A	✅¹	✅¹	✅¹	N/A	N/A	N/A	N/A	N/A
PyPy 3.9 v7.3	✅	✅	✅	N/A	N/A	✅¹	✅¹	✅¹	N/A	N/A	N/A	N/A	N/A
PyPy 3.10 v7.3	✅	✅	✅	N/A	N/A	✅¹	✅¹	✅¹	N/A	N/A	N/A	N/A	N/A
PyPy 3.11 v7.3	✅	✅	✅	N/A	N/A	✅¹	✅¹	✅¹	N/A	N/A	N/A	N/A	N/A
GraalPy 3.11 v24.2	✅	✅	✅	N/A	N/A	✅¹	N/A	✅¹	N/A	N/A	N/A	N/A	N/A

^{¹ PyPy & GraalPy are only supported for manylinux wheels.
² Windows arm64 support is experimental.
³ Free-threaded mode requires opt-in using enable.
⁴ Experimental, not yet supported on PyPI, but can be used directly in web deployment. Use --platform pyodide to build.
⁵ manylinux armv7l support is experimental. As there are no RHEL based image for this architecture, it's using an Ubuntu based image instead.}

• Builds manylinux, musllinux, macOS 10.9+ (10.13+ for Python 3.12+), and Windows wheels for CPython, PyPy, and GraalPy
• Works on GitHub Actions, Azure Pipelines, Travis CI, CircleCI, GitLab CI, and Cirrus CI
• Bundles shared library dependencies on Linux and macOS through auditwheel and delocate
• Runs your library's tests against the wheel-installed version of your library

See the cibuildwheel 1 documentation if you need to build unsupported versions of Python, such as Python 2.

Usage

cibuildwheel runs inside a CI service. Supported platforms depend on which service you're using:

	Linux	macOS	Windows	Linux ARM	macOS ARM	Windows ARM	iOS
GitHub Actions	✅	✅	✅	✅	✅	✅	✅³
Azure Pipelines	✅	✅	✅		✅	✅²	✅³
Travis CI	✅		✅	✅
CircleCI	✅	✅		✅	✅		✅³
Gitlab CI	✅	✅	✅	✅¹	✅		✅³
Cirrus CI	✅	✅	✅	✅	✅

^{¹ Requires emulation, distributed separately. Other services may also support Linux ARM through emulation or third-party build hosts, but these are not tested in our CI.
² Uses cross-compilation. It is not possible to test arm64 on this CI platform.
³ Requires a macOS runner; runs tests on the simulator for the runner's architecture.}

Example setup

To build manylinux, musllinux, macOS, and Windows wheels on GitHub Actions, you could use this .github/workflows/wheels.yml:

name: Build

on: [push, pull_request]

jobs:
  build_wheels:
    name: Build wheels on ${{ matrix.os }}
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-latest, ubuntu-24.04-arm, windows-latest, macos-13, macos-latest]

    steps:
      - uses: actions/checkout@v4

      # Used to host cibuildwheel
      - uses: actions/setup-python@v5

      - name: Install cibuildwheel
        run: python -m pip install cibuildwheel==3.0.0b4

      - name: Build wheels
        run: python -m cibuildwheel --output-dir wheelhouse
        # to supply options, put them in 'env', like:
        # env:
        #   CIBW_SOME_OPTION: value
        #   ...

      - uses: actions/upload-artifact@v4
        with:
          name: cibw-wheels-${{ matrix.os }}-${{ strategy.job-index }}
          path: ./wheelhouse/*.whl

For more information, including PyPI deployment, and the use of other CI services or the dedicated GitHub Action, check out the documentation and the examples.

How it works

The following diagram summarises the steps that cibuildwheel takes on each platform.

^{Explore an interactive version of this diagram in the docs.}

	Option	Description
Build selection	platform	Override the auto-detected target platform
	build skip	Choose the Python versions to build
	archs	Change the architectures built on your machine by default.
	project-requires-python	Manually set the Python compatibility of your project
	enable	Enable building with extra categories of selectors present.
	allow-empty	Suppress the error code if no wheels match the specified build identifiers
Build customization	build-frontend	Set the tool to use to build, either "build" (default), "build[uv]", or "pip"
	config-settings	Specify config-settings for the build backend.
	environment	Set environment variables
	environment-pass	Set environment variables on the host to pass-through to the container.
	before-all	Execute a shell command on the build system before any wheels are built.
	before-build	Execute a shell command preparing each wheel's build
	xbuild-tools	Binaries on the path that should be included in an isolated cross-build environment.
	repair-wheel-command	Execute a shell command to repair each built wheel
	manylinux-*-image musllinux-*-image	Specify manylinux / musllinux container images
	container-engine	Specify the container engine to use when building Linux wheels
	dependency-versions	Control the versions of the tools cibuildwheel uses
	pyodide-version	Specify the Pyodide version to use for pyodide platform builds
Testing	test-command	The command to test each built wheel
	before-test	Execute a shell command before testing each wheel
	test-sources	Files and folders from the source tree that are copied into an isolated tree before running the tests
	test-requires	Install Python dependencies before running the tests
	test-extras	Install your wheel for testing using extras_require
	test-groups	Specify test dependencies from your project's dependency-groups
	test-skip	Skip running tests on some builds
	test-environment	Set environment variables for the test environment
Debugging	debug-keep-container	Keep the container after running for debugging.
	debug-traceback	Print full traceback when errors occur.
	build-verbosity	Increase/decrease the output of the build

These options can be specified in a pyproject.toml file, or as environment variables, see configuration docs.

Working examples

Here are some repos that use cibuildwheel.

Name	CI	OS	Notes
scikit-learn			The machine learning library. A complex but clean config using many of cibuildwheel's features to build a large project with Cython and C++ extensions.
pytorch-fairseq			Facebook AI Research Sequence-to-Sequence Toolkit written in Python.
NumPy			The fundamental package for scientific computing with Python.
duckdb			DuckDB is an analytical in-process SQL database management system
Tornado			Tornado is a Python web framework and asynchronous networking library. Uses stable ABI for a small C extension.
NCNN			ncnn is a high-performance neural network inference framework optimized for the mobile platform
Matplotlib			The venerable Matplotlib, a Python library with C++ portions
MyPy			The compiled version of MyPy using MyPyC.
Prophet			Tool for producing high quality forecasts for time series data that has multiple seasonality with linear or non-linear growth.
Kivy			Open source UI framework written in Python, running on Windows, Linux, macOS, Android and iOS

ℹ️ That's just a handful, there are many more! Check out the Working Examples page in the docs.

Legal note

Since cibuildwheel repairs the wheel with delocate or auditwheel, it might automatically bundle dynamically linked libraries from the build machine.

It helps ensure that the library can run without any dependencies outside of the pip toolchain.

This is similar to static linking, so it might have some license implications. Check the license for any code you're pulling in to make sure that's allowed.

Changelog

v3.0.0

Not yet released, but available for testing.

Note - when using a beta version, be sure to check the latest docs, rather than the stable version, which is still on v2.X.

If you've used previous versions of the beta:

• ⚠️ Previous betas of v3.0 changed the working directory for tests. This has been rolled back to the v2.x behaviour, so you might need to change configs if you adapted to the beta 1 or 2 behaviour. See issue #2406 for more information.
• ⚠️ GraalPy shipped with the identifier gp242-* in previous betas, this has been changed to gp311_242-* to be consistent with other interpreters, and to fix a bug with GraalPy and project requires-python detection. If you were using GraalPy, you might need to update your config to use the new identifier.

v3.0.0b4

29 May 2025

• 🛠 Dependency updates, including Python 3.14.0b2 (#2371)
• 🛠 Remove the addition of PYTHONSAFEPATH to test-environment. (#2429)
• 📚 README table now matches docs and auto-updates. (#2427, #2428)

v3.0.0b3

28 May 2025

• 🛠 Reverts the test working dir (when test-sources isn't set) to a temporary dir, rather than the project. (#2420)
• 📚 Docs now primarily use the pyproject.toml name of options, rather than the environment variable name. (#2389)

v3.0.0b2

25 May 2025

• ✨ Adds the CIBW_TEST_ENVIRONMENT option, which allows you to set environment variables for the test command. cibuildwheel now sets PYTHONSAFEPATH=1 in test environments by default, to avoid picking up package imports from the local directory - we want to test the installed wheel, not the source tree! You can change that, or any other environment variable in the test environment using this option. (#2388)
• ✨ Improves support for Pyodide builds and adds the CIBW_PYODIDE_VERSION option, which allows you to specify the version of Pyodide to use for builds. (#2002)

v3.0.0b1

19 May 2025

• 🌟 Adds the ability to build wheels for iOS! Set the platform option to ios on a Mac with the iOS toolchain to try it out!

• 🌟 Adds support for the GraalPy interpreter! Enable for your project using the enable option. (#1538)

• ✨ Adds CPython 3.14 support, under the enable option cpython-prerelease. This version of cibuildwheel uses 3.14.0b1.

  While CPython is in beta, the ABI can change, so your wheels might not be compatible with the final release. For this reason, we don't recommend distributing wheels until RC1, at which point 3.14 will be available in cibuildwheel without the flag. (#2390)

• ✨ Adds the test-sources option, and changes the working directory for tests.

  • If this option is set, cibuildwheel will copy the files and folders specified in test-sources into a temporary directory, and run the tests from there. This is required for iOS builds, but also useful for other platforms, as it allows you to test the installed wheel without any chance of accidentally importing from the source tree.
  • If this option is not set, cibuildwheel will run the tests in the source tree. This is a change from the previous behavior, where cibuildwheel would run the tests from a temporary directory. We're still investigating what's best here, so if you encounter any issues with this, please let us know in issue #2406.
  • If this option is not set, behaviour matches v2.x - cibuildwheel will run the tests from a temporary directory, and you can use the {project} placeholder in the test-command to refer to the project directory.

• ✨ Added´ dependency-versions inline syntax (#2123)

• 🛠 The default manylinux image has changed from manylinux2014 to manylinux_2_28 (#2330)

• 🛠 Invokes build rather than pip wheel to build wheels by default. You can control this via the build-frontend option. You might notice that you can see your build log output now! (#2321)

• 🛠 Removed the CIBW_PRERELEASE_PYTHONS and CIBW_FREE_THREADED_SUPPORT options - these have been folded into the enable option instead. (#2095)

• 🛠 EOL images manylinux1, manylinux2010, manylinux_2_24 and musllinux_1_1 can no longer be specified by their shortname. The full OCI name can still be used for these images, if you wish (#2316)

• 🛠 Build environments no longer have setuptools and wheel preinstalled. (#2329)

• ⚠️ Dropped support for building Python 3.6 and 3.7 wheels. If you need to build wheels for these versions, use cibuildwheel v2.23.3 or earlier. (#2282)

• ⚠️ The minimum Python version required to run cibuildwheel is now Python 3.11. You can still build wheels for Python 3.8 and newer. (#1912)

• ⚠️ PyPy wheels no longer built by default, due to a change to our options system. To continue building PyPy wheels, you'll now need to set the enable option to pypy or pypy-eol. (#2095)

• ⚠️ Dropped official support for Appveyor. If it was working for you before, it will probably continue to do so, but we can't be sure, because our CI doesn't run there anymore. (#2386)

• 📚 A reorganisation of the docs, and numerous updates (#2280)

---

That's the last few versions.

ℹ️ Want more changelog? Head over to the changelog page in the docs.

---

Contributing

For more info on how to contribute to cibuildwheel, see the docs.

Everyone interacting with the cibuildwheel project via codebase, issue tracker, chat rooms, or otherwise is expected to follow the PSF Code of Conduct.

Maintainers

• Joe Rickerby @joerick
• Yannick Jadoul @YannickJadoul
• Matthieu Darbois @mayeut
• Henry Schreiner @henryiii
• Grzegorz Bokota @Czaki

Credits

cibuildwheel stands on the shoulders of giants.

• ⭐️ @matthew-brett for multibuild and matthew-brett/delocate
• @PyPA for the manylinux Docker images pypa/manylinux
• @ogrisel for wheelhouse-uploader and run_with_env.cmd

Massive props also to-

• @zfrenchee for help debugging many issues
• @lelit for some great bug reports and contributions
• @mayeut for a phenomenal PR patching Python itself for better compatibility!
• @czaki for being a super-contributor over many PRs and helping out with countless issues!
• @mattip for his help with adding PyPy support to cibuildwheel

See also

Another very similar tool to consider is matthew-brett/multibuild. multibuild is a shell script toolbox for building a wheel on various platforms. It is used as a basis to build some of the big data science tools, like SciPy.

If you are building Rust wheels, you can get by without some of the tricks required to make GLIBC work via manylinux; this is especially relevant for cross-compiling, which is easy with Rust. See maturin-action for a tool that is optimized for building Rust wheels and cross-compiling.