Weave Code
A FastCGI daemon written in PHP.
Frequently asked questions about Fastcgi Daemon
- What is phpfastcgi/fastcgi-daemon and is it a Laravel package?
- It is a FastCGI protocol implementation plus a ReactPHP-based event-loop server harness written in PHP, distributed as a Composer package. It is not a Laravel integration library: it ships no service provider, no facade and no Laravel awareness. Adopting it means replacing PHP-FPM as the request-execution substrate for at least one service, which is an infrastructure decision rather than a normal dependency addition.
- Does phpfastcgi/fastcgi-daemon work with Laravel out of the box?
- No. The package supplies transport and a kernel abstraction only, so you must write a custom KernelInterface implementation yourself. That kernel has to bootstrap Laravel once, translate FastCGI params such as REQUEST_METHOD, SCRIPT_FILENAME, QUERY_STRING, headers and the body stream into an Illuminate\Http\Request, dispatch through the HTTP kernel and serialize the response back into FastCGI records. You also have to reset container state, Eloquent connections, auth, sessions and static caches between requests.
- How do I install phpfastcgi/fastcgi-daemon with Composer?
- Composer require phpfastcgi/fastcgi-daemon will resolve against a composer.json written in 2018, so the safer route is to vendor or fork the package under your own namespace and pin it. Expect to widen or replace the ReactPHP version constraints and to fix PHP 8 deprecations such as implicit nullable parameters, dynamic properties and dollar-brace string interpolation. Do not rely on Packagist resolution alone for a modern Laravel codebase.
- Which PHP and Laravel versions does phpfastcgi/fastcgi-daemon support?
- The last release was August 2018, which places it in the PHP 7.x and ReactPHP 0.4 to 0.5 era. PHP 8.x and modern ReactPHP 1.x compatibility are unverified and likely to require a fork plus patched constraints. There is no declared Laravel version support because the package has no Laravel integration at all.
- How much work is it to integrate phpfastcgi/fastcgi-daemon with a Laravel application?
- Budget it as a multi-sprint engineering project rather than an afternoon of wiring. You are effectively reimplementing the Octane problem statement from scratch: long-lived bootstrap, FastCGI request translation, response serialization and full state reset between requests. Integration feasibility is low to moderate and almost entirely self-built.
- Is phpfastcgi/fastcgi-daemon maintained and safe for production?
- Release activity stopped in August 2018, there are zero dependent projects and there is no published validated integration path to copy. The FastCGI record parser sits directly on untrusted request bytes, so any CVE response would fall entirely to your team. Treat upstream maintenance and security risk as high and plan to own the fork.
- What are the alternatives to phpfastcgi/fastcgi-daemon for running Laravel in a long-lived process?
- Laravel Octane with Swoole, RoadRunner or FrankenPHP is the mainstream answer and ships maintained Laravel integration. Plain PHP-FPM with OPcache and preloading remains the baseline for stock deployments. Only consider this package if you have a genuine FastCGI-only constraint or are deliberately spiking a custom application-server architecture.
- Will phpfastcgi/fastcgi-daemon make my Laravel app faster than PHP-FPM?
- Not automatically. The long-lived process avoids per-request framework bootstrap, but Laravel's synchronous lifecycle means any blocking call such as a DB query, HTTP client request or file I/O stalls the entire event loop. Real deployments need a process manager fronting N single-threaded workers, which recovers FPM-style parallelism but discards most of the event-loop benefit. Benchmark against FPM with OPcache and preloading enabled before assuming a gain.
- How should I deploy phpfastcgi/fastcgi-daemon alongside an existing Laravel stack?
- Do not migrate. Run it in parallel as an isolated service behind its own fastcgi_pass upstream, route a single low-risk read-only endpoint to it and keep FPM serving everything else. Confirm the package's own multi-process and forking support before assuming it is provided, and verify the exact parameter set your nginx or Apache build sends.
- Does phpfastcgi/fastcgi-daemon handle keep-alive, multiplexing and concurrent requests correctly?
- Treat multiplexing and keep-alive semantics as unvalidated until you test them against your specific web server build. With no upstream activity and no downstream dependents, there is no reference implementation confirming these behaviours. Write protocol-level tests for the record parser and connection handling before exposing the daemon to real traffic.
Weaver
How can I help you explore Laravel packages today?