- What is roadrunner/worker and what does it actually do?
- It is the base PHP worker for the RoadRunner application server. The worker receives payloads over the Goridge protocol, dispatches them to your application code, sends responses back, and manages the worker pool lifecycle. It is a low-level runtime component rather than an application-level library, and it is framework-agnostic with PSR-7 and PSR-17 oriented interfaces.
- How do I install roadrunner/worker with Composer?
- You install it with composer require roadrunner/worker. In most Laravel setups you will not add it manually, because it arrives transitively through Laravel Octane's RoadRunner driver or a bridge package. Confirm your bridge supports the new roadrunner/worker name before requiring it explicitly, since a bridge still pinned to spiral/roadrunner-worker can cause a dependency conflict or a duplicate vendor tree.
- Is roadrunner/worker the same package as spiral/roadrunner-worker?
- Yes. As of v3.8.0 the package is formally named roadrunner/worker, previously spiral/roadrunner-worker, so treat the change as an identity move rather than a rewrite. Check that bridge packages, internal allowlists and vulnerability scanner rules reference the new name, otherwise the package can quietly drop out of your supply-chain visibility. Ask the bridge maintainers about the EOL timeline for the old name.
- Does roadrunner/worker work with Laravel and Laravel Octane?
- Yes, but indirectly. Laravel teams usually reach RoadRunner through Octane's RoadRunner driver or a bridge package that pulls this worker in transitively. The package itself is framework-agnostic, so Laravel-specific bootstrapping, configuration and lifecycle hooks come from the adapter layer rather than from this repository.
- Which PHP and Laravel versions does roadrunner/worker support?
- Version 3.8.0 raises the minimum PHP requirement to 8.2. The package does not target a specific Laravel version because it is framework-agnostic, so Laravel compatibility is determined by Octane or your bridge package. Verify the PHP 8.2 floor against your minimum supported runtime before updating, because a transitive bump can silently block composer update on older services.
- Do I need to require roadrunner/worker directly in a Laravel application?
- Usually no. Application code should not reference the worker directly, because it is an implementation detail of the RoadRunner adapter. Requiring it explicitly only makes sense if you are writing a custom worker bootstrap, which should be a deliberate architecture decision rather than an incidental composer require.
- How does the PHP worker communicate with the RoadRunner server binary?
- The worker runs as a long-lived PHP process that speaks the Goridge protocol to the RoadRunner Go binary. It reads request payloads from the socket, hands them to your handler, and writes the PSR-7 response back over the same channel. Because the binary and the PHP worker are versioned separately, keep them on compatible releases to avoid protocol mismatches.
- How do I prevent state leaking between requests in long-running RoadRunner workers?
- Persistent workers keep singletons, static state and open database connections alive across requests, so anything request-scoped must be reset. Avoid storing request data on long-lived objects, clear container bindings and authenticated user state per request, and be careful with connection pooling. Treat this as a correctness and security concern rather than a minor bug class.
- How do I test an application that runs on RoadRunner workers?
- Test your handlers as ordinary PHP or Laravel code, since the worker only delivers payloads and returns responses. For end-to-end coverage, run the actual rr binary against your application and exercise the request lifecycle, including error paths and worker restarts. Also run repeated requests through the same process to catch state leaking between calls.
- What are the alternatives to roadrunner/worker, and is it actively maintained?
- Alternatives include Laravel Octane with the Swoole or FrankenPHP drivers, or staying on classic PHP-FPM. Maintenance looks active, since v3.8.0 combines a rename, a PHP floor raise and refactoring, but adoption signals are weak because this is a low-level component consumed transitively rather than installed directly. Note that a rename typically resets adoption metrics, so low star counts and dependent numbers should not be read as the package being unused.