Skip to content

Choose a target

PAM uses the same persistent PHP foundation across several application targets, but each target has a different maturity and deployment model.

Whichever target you choose, the thesis is the same: PHP should be allowed to own complete applications while purpose-built Rust and native layers handle the boundaries that demand them. Choose by product need and verified maturity, not by fear that PHP can only live behind a request-response server.

You want to build Start with Current boundary
HTTP service pam init my-api --template http PAM 1.0 on Linux x86_64/ARM64
Laravel application pam init my-app --template laravel Laravel 12 and 13 executable matrix
Real-time server Add --socket to API or Laravel Native RFC 6455 transport
Native application, low-level UI pam init my-app --template native Android API 26–36; generated iOS host and simulator certification
Desktop application pam init my-app --template desktop Linux experimental; macOS/Windows planned

Choose the server runtime when you need persistent HTTP, streaming, WebSockets, background I/O, or high-throughput APIs without leaving PHP and Composer.

Choose Laravel when you want the Laravel application model and ecosystem. PAM boots the framework once, creates an isolated application sandbox for each request, and limits the host to one concurrent request per worker because Laravel and many packages keep mutable process-global state.

Choose PAM Native when you want real platform controls while keeping application state and composition in PHP. It is not a WebView and does not include React’s JavaScript runtime.

Choose Desktop for controlled prototypes where PHP owns the application and Servo renders local HTML, CSS, and JavaScript. The native bridge is capability-based and disabled by default. Linux packaging exists today; Windows, macOS, signing, and automatic updates remain roadmap work.