Introduction

PAM stands for PHP, Always in Memory — and it is an unapologetically ambitious answer to a simple question: how far can PHP go when we stop treating it as a language that must be rebuilt and discarded on every request?

The answer is: much further than the traditional runtime boundary suggests. PAM keeps the Zend Engine and your Composer application alive inside a supervised, event-driven runtime powered by Rust, Tokio, and PHP Fibers. The same foundation can serve persistent HTTP and WebSocket workloads, run Laravel with isolated request sandboxes, render real native mobile controls, and power capability-secured desktop software.

This is not PHP imitating another ecosystem. It is PHP operating with a modern systems boundary built specifically around its strengths.

Start with a running product

Choose Server, Laravel, Native, or Desktop, then create it with one pam init command. Official product capabilities are available through the PAM capability catalog.

Traditional PHP                      PAM

request                              process starts
├─ bootstrap PHP                     ├─ start Zend + Tokio
├─ load Composer                     ├─ load Composer
├─ build application                 ├─ build application once
├─ execute handler                   ├─ request 1 ─┐
└─ discard state                     ├─ request 2 ─┼─ isolated Fibers
request                              └─ request N ─┘
└─ repeat                               process stays alive

What PAM is

• A small PHP Embed runtime with a Rust and Tokio execution boundary; official bundles use PHP 8.5 by default and retain PHP 8.4 as a compatibility runtime.
• Persistent processes, request/response transport, Fibers, native asynchronous I/O, isolation and supervision.
• The runtime underneath independent Composer products such as PAM HTTP, Laravel on PAM, PAM Native and PAM Desktop.

PAM itself is not those products and does not own their application APIs. Composer packages provide routing, frameworks, UI, integrations and package commands using the same public extension contract as community packages.

Why PAM is different

Most platforms force a choice: keep the PHP ecosystem and accept the classic request lifecycle, or leave PHP to gain persistent processes, native interfaces, desktop distribution, and systems-level control.

PAM rejects that trade-off.

Your application remains PHP. Composer remains Composer. Laravel remains Laravel. Rust owns the work that benefits from strict memory, concurrency, and native control. PHP owns the expressive application layer developers already understand. Between them sits an explicit, versioned, bounded contract instead of an accidental pile of bridges.

That combination is technically difficult, deliberately opinionated, and rare. We are proud of it. PAM is not a wrapper around an existing JavaScript stack, not a renamed process manager, and not a demo that stops at “Hello World.” It is an attempt to give PHP a coherent application platform from the server process to the screen.

One foundation, distinct products

PAM Server

PAM Server turns PHP into a supervised persistent runtime for HTTP, WebSockets, streaming, native asynchronous I/O, workers, and durable process lifecycles. Zend stays warm; Rust and Tokio own transport, scheduling, and supervision. You keep normal PHP and Composer while gaining a runtime designed for long-lived work.

Laravel on PAM

Laravel on PAM keeps the framework developers love and changes the operational ceiling around it. The application boots once, each request receives an isolated sandbox, and the production layer adds diagnostics, OTLP observability, managed processes, atomic releases, autoscaling, Cloud and Forge operations, and bounded MCP automation.

PAM Native

PAM Native renders actual Android Views and UIKit controls from PHP. There is no WebView pretending to be native and no React JavaScript runtime between application state and the platform UI. PHP owns composition, Rust owns validation, reconciliation and layout, and Kotlin or Swift commits native mutations where they belong.

PAM Desktop

PAM Desktop combines typed PHP application logic, Rust process control, and Servo-rendered interfaces inside capability-secured native windows. Commands, events, filesystem access, plugins, updates, rollback, and distribution are explicit contracts — not unrestricted ambient access disguised as convenience.

PAM Packages

PAM’s package ecosystem keeps optional abstractions optional. Routing, WebSockets, PSR interoperability, testing, native UI, and extension contracts remain ordinary Composer packages with versioned public APIs. PAM expands what PHP can host without replacing the ecosystem that made PHP valuable.

Start a server application with pushinbr/pam-http, the Express-like HTTP layer with controller method mapping, Laravel-style route groups, dependency injection, request-scoped services, dedicated validation, Resources, middleware and production-safe error boundaries.

What PAM is not

PAM is not a new programming language, a PHP fork, a framework, or a Composer replacement. A standard composer.json, composer.lock, PSR-4 autoloader, and vendor/autoload.php remain the project contract.

It also does not make every synchronous PHP library asynchronous. A blocking extension or library blocks its worker while it runs. Use PAM-native I/O, a compatible event-loop package, a process pool, or multiple workers depending on the workload.

Current maturity

PAM 1.0 stabilizes the CLI, server runtime contracts, project generators, official Composer packages, editor tooling, Android distribution, and the generated iOS host. Android is certified on APIs 26 and 36. iOS is certified in real simulators with PHP 8.4 and 8.5, including Share Extension, Health, Media, Widgets, App Intents, and Live Activities. Signed device and store delivery still depend on the application owner’s Apple credentials and provisioning.

“1.0” is a compatibility commitment for the documented public contracts, not a claim that every PHP extension, Composer package, device, or workload is automatically safe. The project status page defines each boundary and the 1.0 release record links the executable evidence.