Manticore 0.18 compiles Laravel and Symfony into native binaries

Reducing the moving parts in a PHP deployment

In a homelab, every extra runtime component becomes another thing to patch, monitor, and debug. A typical PHP deployment includes the interpreter, extensions, configuration, a web server or PHP-FPM, and the glue between them. Manticore takes a different approach: it ahead-of-time compiles PHP into a native binary that runs without a PHP runtime installed on the target machine. (github.com)

Version 0.18 matters because this is no longer only about small scripts. The project ships a Laravel example using web and JSON routes, Eloquent with SQLite, sessions, Blade, Carbon, and Monolog, and it compiles into one binary that serves requests. It also builds symfony/demo as a native binary capable of serving the application. (github.com)

What is different from a regular Laravel deployment

This does not turn Laravel into a static site, and it does not remove the need for data, secrets, or persistent storage. What changes is how the application code is packaged and started: the resulting program does not load vendor/autoload.php at runtime or require a separate PHP process. For an internal tool, a small API, or a tightly scoped self-hosted service, that is worth testing. (github.com)

I find the idea useful for services I want to recreate without managing extension versions or carrying a large base image. Manticore provides a Docker image with the required toolchain already included, which makes the build environment easier to pin and reproduce. That works well with a repository, a simple pipeline, and a binary artifact deployed later to another VM or container. (github.com)

A reproducible first run

The quickest way to test the compiler is to mount the current directory into the official image and produce a binary from a PHP file. The command published for version 0.18.0 is:

docker run --rm -v "$PWD":/work -u "$(id -u):$(id -g)" \
  ghcr.io/manticorephp/compiler:0.18.0 manticore compile app.php -o app

For a full application, I would not replace an existing deployment process on day one. I would start with the project’s own examples/laravel-app, inspect what differs from a standard Laravel skeleton, and automate that build in a test branch. That gives me a chance to validate routes, migrations, sessions, storage, and failure modes before deciding whether the approach fits a real service. (github.com)

The important caveats

I would not treat this as a production replacement for PHP-FPM. The release announcement explicitly says the compiler is not production-ready yet, and the release notes still list known Symfony demo issues, including per-request leaks and unsafe concurrent requests in a single worker. (reddit.com)

A native binary is not automatically a fully static executable either. Generated programs dynamically link against system libraries, and their dependency set grows when they use features backed by libraries such as SQLite, cURL, or PCRE2. Docker makes compilation easier, but the target environment still needs compatible libraries. (github.com)

That is why I see Manticore as a tool for learning, measuring, and simplifying highly controlled deployments rather than a blanket Laravel migration strategy. I would begin with a small SQLite-backed app, disposable data, and known traffic patterns, while keeping conventional PHP as the functional baseline. If the compiled binary preserves the behavior I need and cuts operational work, then it earns a larger experiment. (github.com)

• Source: r/PHP announcement
• Official documentation and version 0.18.0