PeachPie: compiling PHP to .NET with Roslyn

The gap PeachPie fills between PHP and .NET

Most teams that run both PHP and .NET keep them apart: a PHP process behind a web server, a .NET process behind another, and an HTTP or message-broker boundary in between. PeachPie removes that boundary by compiling PHP source into .NET assemblies. The README frames the goal as both-way interoperability, so a hybrid application can have parts written in C# and parts written in PHP, with the parts communicating inside the same framework rather than across a network hop.

The audience follows from that. It is not aimed at someone who just wants to serve WordPress faster; it is aimed at engineers who already own a .NET codebase and have PHP they cannot easily rewrite, or PHP developers who want their code to run under the .NET runtime and be distributed as a portable class library. The README also lists source-less distribution as a benefit, since compiled applications do not ship readable PHP.

Roslyn as the front end and a reimplemented runtime at the back

PeachPie is described as a modern PHP compiler based on the Microsoft Roslyn compiler platform. That is the architectural decision everything else follows from: rather than writing a parser and code generator from scratch, the project plugs PHP into the same compiler infrastructure Microsoft uses for C#, which is why the repository topics include roslyn alongside php-compiler.

The second half is the runtime. The README states that compiled programs run on a reimplemented PeachPie runtime that is meant to be fully compatible with the PHP runtime. So there are two distinct pieces to reason about: the compile step, which turns PHP into .NET assemblies, and the runtime library, which supplies the PHP semantics those assemblies expect. The repository layout reflects this split, with src/ holding the compiler and runtime sources, tests/ holding the test suites, and build/ and tools/ holding the build plumbing.

One claim in the README deserves a caveat. It says the extensive type analysis and the influence of Roslyn should provide improved performance. That is a stated expectation, not a measured result, and the README offers no figures. Treat performance as something you establish on your own workload.

Installing PeachPie and building a first project

The README gives two routes: a Visual Studio extension that adds project templates, build and debug support, profiling through the VS diagnostic tools and Azure deployment, and command line use through dotnet. VS Code and Rider are named as editors that can also build and debug PeachPie projects. The README points to a short introduction video and to the Getting Started section of docs.peachpie.io for the command line path, and it notes that the most convenient way to consume PeachPie is through NuGet packages.

The repository itself is a .NET solution, so the conventional starting point is the solution file:

dotnet build Peachpie.sln

Building the solution compiles the compiler and runtime projects under src/ together with their test projects. Expect this to pull NuGet dependencies restored through the NuGet.Config in the repository root, so the first build is slower than later ones.

For application work rather than compiler work, the README directs you to the Visual Studio extension for templates, or to the command line and the Getting Started documentation. The extension is installed from the Visual Studio Marketplace under the publisher iolevel. Once a project is created from a template, the README describes the extension as handling build, debug and profiling, which means the PHP source is compiled into an assembly as part of the normal build.

Access to nightly builds and release builds is tied to Patreon sponsorship, according to the README. That is an unusual distribution detail for an open source compiler and worth knowing before you plan a dependency on a specific build cadence.

Where the compatibility boundary actually sits

The README does not claim complete PHP coverage. It says the project is a work in progress, that the list of finished and planned features changes frequently, and it sends readers to two places: a Roadmap section and a Compatibility overview on docs.peachpie.io. That is the honest position, and it is also the main risk. A compiler that covers most of a language is not useful if the part it misses is the part your application depends on.

There is a second limit that is easy to overlook. PeachPie targets the .NET runtime, and the README presents security partly as a consequence: code runs within the standardized .NET or .NET Core environment and is fully verifiable without unsafe constructs. That framing implies the PHP code you compile is expected to fit that model. PHP that relies on runtime evaluation of arbitrary strings, on dropping into native extensions, or on the exact behaviour of the standard PHP interpreter in edge cases is where a reimplemented runtime is most likely to diverge.

Finally, the project describes itself as maintained in the maintainers' spare time. The last push to the default branch was on 2026-09-26, which is recent, but the release history is uneven: v1.1.13 in November 2025, v1.1.11 in February 2025, and v1.1.10 in August 2024. Plan for gaps between releases rather than a steady cadence.

PeachPie against running PHP under its own interpreter

The obvious alternative is not another compiler; it is the PHP interpreter itself, either behind a web server or embedded through the PHP embedding API in a native host. The difference in approach is fundamental. The interpreter executes PHP source at request time and its behaviour is the reference implementation. PeachPie moves the work to build time, produces .NET assemblies, and then has to reproduce that behaviour on top of a runtime it wrote.

That trade buys things the interpreter cannot offer. Compiled PHP becomes a portable class library, so it can be referenced from C# the way any other assembly is. It can be distributed without source. It runs inside the same process as the rest of a .NET application, so no cross-process call is needed for PHP code and C# code to interact. What it costs is fidelity: every construct the PeachPie runtime does not implement is a construct you cannot use, and the README's own pointer to a compatibility overview is an admission that the set of such constructs is non-empty and changing.

A second alternative is rewriting the PHP into C#. That gives up the existing code entirely, which is exactly the cost PeachPie exists to avoid.

Licence, upgrade cost and how the project is funded

PeachPie is licensed under Apache-2.0, with the licence text at LICENSE.txt in the repository root. That is a permissive licence, and it is the same licence family the surrounding .NET ecosystem generally expects. The project is also a member project of the .NET Foundation, which the README states and which the repository acknowledges with a logo under docs/logos. Membership does not change the licence terms, but it does place the project inside a known governance structure.

Upgrade cost is shaped by the release pattern rather than by the licence. With releases spaced months apart, you are either pinning a specific version and living with it, or tracking the default branch. The README's note that nightly and release builds are provided to Patreon subscribers adds a second consideration: if your organisation needs a predictable build feed, that access is tied to sponsorship rather than to a public channel.

The compatibility surface is the real upgrade cost. Because the project tracks PHP language coverage and updates it regularly, a version bump can move the boundary of what compiles and what behaves correctly. Any upgrade should be paired with a rebuild of your own test suite, not just a version change in a project file. Nothing here is legal advice; read LICENSE.txt and the .NET Foundation's own terms if the distinction matters to you.

Editorial conclusion

Adopt PeachPie when you have PHP that must run inside a .NET process, or C# that must call PHP code, and when you can pin a release and check the compatibility overview for every language feature you depend on. Do not adopt it expecting a drop-in replacement for the PHP interpreter across an arbitrary legacy codebase; the README itself calls PeachPie a work in progress and points at a dynamic roadmap. Before committing, open docs.peachpie.io/php/Compatibility/ and confirm the extensions and syntax your project uses are listed, then build one representative project from the command line and inspect the produced assembly.

Frequently asked questions

Official sources

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