Weave Code
Process Laravel Package
amphp/process
amphp/process is an asynchronous process dispatcher for PHP 8.1+ built on the Revolt event loop. It runs child processes on all major platforms, including Windows, with non-blocking access to stdout and stderr, plus support for custom working directories and environment variables.
A fiber-aware process manager based on Amp and Revolt.
Frequently asked questions about Process
- Can I use amphp/process in a Laravel application?
- Yes, but its value is limited to long-running CLI contexts such as Artisan commands, queue workers, Horizon supervisors, and custom daemons. In standard PHP-FPM request lifecycles there is no event loop to yield to, so it behaves much like Symfony Process with extra dependencies. Treat it as a CLI-plane tool rather than a framework-wide replacement.
- Does amphp/process work with Laravel Octane?
- It depends on the Octane driver: layering Revolt on top of Swoole's own event loop is not a supported composition, while RoadRunner is more tractable but still non-trivial. For most Laravel teams, keeping amphp/process out of Octane workers and isolating it in dedicated CLI workers is safer. Validate your driver and runtime discipline before relying on it in production.
- How do I install amphp/process in Laravel?
- Install it with composer require amphp/process; it requires PHP 8.1 or later and is MIT licensed with a stable v2.0.x line. Because the package is framework-agnostic, Laravel compatibility is bounded mainly by that PHP requirement. Wrap it behind an application-level ProcessRunner interface instead of exposing Amp types across your codebase.
- Is amphp/process a drop-in replacement for Symfony Process in Laravel?
- No. Symfony Process is blocking and safe anywhere, while amphp/process requires an Amp/Revolt event loop and strict avoidance of blocking calls inside that loop. The API surface is small, so an adapter is thin, but the runtime discipline is all-or-nothing per worker class. Use a config flag to choose between a blocking runner and an async runner.
- What Laravel workloads benefit from amphp/process?
- The best fits are queue-worker or daemon workloads that fan out many concurrent short subprocesses, such as media transcoders, PDF renderers, linters, git commands, or CLI-backed external APIs. Log and metric tailing or batch fan-out jobs can also benefit. Poor fits include HTTP controllers, Blade rendering, synchronous Artisan commands, and anything touching Eloquent mid-loop.
- Can I use Eloquent, PDO, or Redis inside an amphp/process event loop?
- You should avoid blocking calls such as Eloquent/PDO, phpredis, sleep(), and ordinary file I/O once an Amp event loop is running in a worker. Those calls stall every concurrent child process in that loop, and the failure mode is usually slowness rather than a clear error. Keep database and cache access outside the async loop, or isolate async workloads to dedicated worker pools.
- How does amphp/process support Windows in Laravel projects?
- On Windows, amphp/process uses a bundled process wrapper binary because Windows pipes are file handles and do not allow non-blocking access. That makes cross-platform behavior possible but introduces supply-chain scanning, antivirus false positives, and artifact-size friction, especially for Octane or PHAR deployments. Linux-only production may avoid the issue, but Windows dev parity in CI still needs consideration.
- What are the zombie process risks with amphp/process?
- Cleanup depends on optional ext-pcntl, and many container images omit that extension. Recent releases such as v2.0.2 explicitly address FPM zombie leakage, which shows this is a live operational concern. Audit your base images and process cleanup behavior before running this in long-lived workers.
- How should I test amphp/process code in a Laravel application?
- Wrap Process, streams, and exit codes behind your own ProcessRunner interface so tests can use a simple fake or the existing Symfony Process-backed runner. Exercise the Amp-backed implementation in CLI-focused integration tests that start a real event loop and avoid blocking Laravel facades. This keeps test doubles simple and gives you a one-line rollback if async behavior misbehaves.
- What are alternatives to amphp/process for running child processes in Laravel?
- Symfony Process is the default blocking choice and is safe in HTTP, queue, and CLI contexts. Native exec or shell execution is simpler but offers weaker control over pipes, environment, and exit handling. Consider amphp/process only when you need non-blocking fan-out inside an Amp/Revolt event loop and can isolate that workload.
Weaver
How can I help you explore Laravel packages today?