I would suggest first verifying that you are using the official Mendix Cloud Foundry Buildpack v5.0.30 release ZIP file, rather than the GitHub source repository or a manually re-packaged version. The official release artifact already contains the required vendorized Python wheels. If the buildpack is pushed from source, it may attempt to install dependencies dynamically during staging, which can trigger compilation of packages such as cffi. When that happens, the build requires Python.h (Python development headers), which are not available in the staging container, leading to the failure you are seeing.

I would also recommend avoiding manually injecting the Python runtime into the environment. Instead, in restricted environments, the more robust approach is to mirror cdn.mendix.com internally and configure the BLOBSTOREenvironment variable to point to that internal mirror. This allows the buildpack to download the exact Mendix-provided Python package it expects, without internet access, and avoids subtle mismatches that can cause wheel compilation.

In summary, my recommendation would be to ensure you are using the official buildpack release ZIP and to implement an internal CDN mirror via BLOBSTORE rather than manually supplying Python. In most similar scenarios, correcting the buildpack packaging and offline strategy resolves the cffi and Python.h errors.

If this resolves the issue, please close the topic.

Hi,

What you are running into is a known limitation when running the Mendix Cloud Foundry buildpack in a restricted / offline environment.

In buildpack 5.x, Python is used internally for some build steps (for example when installing packages through pip). During that step, packages such as cffi may need to compile native extensions. When that happens, the compiler looks for the Python development headers (Python.h), which are normally provided by the Python development package.

In the standard online flow this works because the buildpack downloads a complete prebuilt Python runtime that already includes the required headers. When you manually provide only the Python runtime tarball offline, the environment may be missing the development headers, which is why the build fails with:

fatal error: Python.h: No such file or directory

So the problem is not really Mendix itself, but that the offline Python package does not include the Python development files needed for compiling dependencies.

A couple of things that usually resolve this:

1. Make sure the Python artifact you provide offline is the exact buildpack dependency expected by the buildpack version (same version and packaging as defined in the buildpack manifest). If it is repackaged manually, the headers might be missing.
2. Ensure the Python distribution contains the development headers (include/python3.x/Python.h). If they are not present, the buildpack cannot compile packages like cffi.
3. In restricted environments it is often easier to pre-build the Python wheels for the required dependencies (such as cffi) and provide them in an internal artifact repository, so the buildpack does not attempt to compile them.
4. If possible, verify whether your platform team can mirror the official Mendix buildpack dependencies internally rather than manually packaging Python. That way the buildpack behaves exactly like the supported configuration.

In short: the failure is happening because the Python runtime provided offline does not include the development headers required to compile dependencies like cffi. Providing the full Python buildpack dependency (including headers) or prebuilt wheels usually resolves the issue.