PHP Desktop: Package a PHP Web App as a Windows or Mac Desktop Executable

What PHP Desktop actually replaces

The README frames the project as "Electron for PHP", and the comparison is the useful one. A PHP web application normally needs a web server, a PHP interpreter and a browser pointed at a URL. PHP Desktop collapses all three into one portable folder: an embedded browser, a multi-threaded web server and a PHP interpreter in a single application. The audience is developers who already ship PHP code and want a desktop build without rewriting it against a new API. The README states plainly that there is no new framework to learn and that converting a site is "basically a matter of copying it to the phpdesktop/www/ directory". That is the whole pitch, and it holds only if your application is a normal request-and-response PHP app rather than something that depends on server modules the embedded stack does not provide.

The embedded stack: browser, Mongoose, PHP-CGI

The architecture is three processes cooperating. The embedded web server is described as a custom edition of Mongoose, and the package with Chrome embedded is said to have no external dependencies. PHP runs through CGI rather than as a long-lived module, and the README draws a specific consequence from that: when a script finishes, the PHP-CGI process is killed and its memory is freed. This is the answer to the usual objection that PHP was never designed to stay resident for days. It is a real design decision with a real cost: every request pays process startup, and anything you would normally keep in memory between requests, such as an opcode cache or a persistent connection pool, is not available in the same way. The README presents the CGI model as the fix for memory growth, and for a desktop app that idles between user actions that trade is usually acceptable.

Installing PHP Desktop and running a first app

There is no package manager step. The README points to release downloads per platform: PHP Desktop Chrome 130.1 for Windows, PHP Desktop Chrome 130.1 for Mac, and PHP Desktop Chrome 72.1 for Linux. Download the archive for your platform, unpack it, and you have the portable folder. The application code lives under phpdesktop/www/, so a first run is a matter of putting an index file there.

mkdir -p phpdesktop/www
echo '<?php echo "hello from php desktop"; ?>' > phpdesktop/www/index.php

Start the bundled executable from the unpacked folder. According to the README, the embedded Chrome package has no external dependencies and works out of the box, so the window should open and render the line you wrote. From that point the development loop is the web loop you already know: edit files under www/, reload. The README points to the Settings and Chrome settings wiki pages for configuration, and to a Knowledge Base page for building an installer with Inno Setup when you are ready to distribute.

Platform coverage is the weak point

The download table is where the project's limits show. Windows and Mac have 130.1 releases. Linux sits at Chrome 72.1. The README lists "New Linux release with latest Chromium" as an ongoing funding item, which means it is not done. If your users are on Linux, you are shipping a browser engine several years behind the other platforms, and any modern web API your front end uses may simply not exist there. The sponsor wish list goes further: cross-platform support with full functionality on Mac and Linux, HTTPS/SSL support, more JavaScript and PHP APIs for desktop tasks, taskbar and systray integration, and SQLite encryption are all listed as proposals rather than shipped features. Read that list as the honest boundary of what the project does today.

PHP Desktop compared with ExeOutput for PHP

ExeOutput for PHP is the alternative that comes up most often, and the difference is in the business model and the packaging pipeline rather than the runtime idea. Both turn PHP into a distributable desktop application. PHP Desktop is released under a non-restrictive license and the README states it is free for commercial closed-source projects; it ships as a portable folder you can zip or wrap in an Inno Setup installer. ExeOutput is a commercial product built around producing a compiled executable. If your constraint is a permissive license and a folder you control end to end, PHP Desktop fits. If your constraint is a signed single binary produced by a vendor toolchain, that is a different purchase decision. The README does not compare itself to ExeOutput, so treat the distinction as one of packaging and licensing, not of measured performance.

Maintenance, releases and what upgrading costs you

The last push to the repository was on 2026-07-31, so the project is not dormant. The release history is uneven, though: chrome-v130.1 for Windows landed on 2024-11-12, mac-v130.1 on 2025-02-01, and mac-v130.0 on 2024-11-10. The README asks for sponsors precisely to fund "monthly releases with latest Chrome" and an automated build system, which tells you the cadence is manual and funding-dependent today. Upgrading means replacing the whole folder, because the browser engine, the server and the PHP interpreter are shipped together. There is no documented rollback procedure in the README; if a new Chromium breaks a front-end feature, you keep the previous archive. On licensing, the README describes the license as non-restrictive and free for commercial closed-source use, and it links to PHP encoders for protecting sources. That is the project's own statement; check the actual license file in a release before you rely on it for a commercial product.

Converting an existing PHP site: what to check first

The README says all popular PHP frameworks are supported and points to a wiki page with example configurations for CakePHP, CodeIgniter, Laravel, Symfony, Yii and Zend Framework. That page is where you should start, because framework front controllers and rewrite rules are exactly the kind of thing an embedded server may handle differently from Apache or nginx. The README also links to a Knowledge Base section on protecting PHP sources in the www directory, which matters if you are distributing to end users who can open the folder. Two things are not covered in the README: how the embedded server maps URLs to files, and whether your application's absolute paths survive the move. Both are worth confirming against the wiki before you commit to the port.

Editorial conclusion

Adopt PHP Desktop if you already have a PHP web application and want a portable Windows or Mac folder without learning a new framework. Do not adopt it if you need a current Chromium on Linux, HTTPS inside the embedded server, or a monthly release train; the README lists HTTPS/SSL support and a new Linux release as unfunded proposals. Before committing, verify the release tag that matches your target platform, check the Settings and Chrome settings wiki pages for the configuration keys your app needs, and confirm that copying your project into phpdesktop/www/ does not break any path that assumes a document root.

Frequently asked questions

Official sources

1. cztomczak/phpdesktop on GitHub
2. Issues
3. Project website
4. README
5. Releases