- Is luzrain/workerman-bundle a Laravel package?
- No. It is a Symfony bundle that integrates Workerman by booting a Symfony Kernel inside a long-lived worker loop. There is no Laravel service provider, no publishable config, and no Laravel-facing API. Using it in Laravel means treating it as a dependency or reference implementation and writing your own bridge.
- Can I install luzrain/workerman-bundle in a Laravel application with Composer?
- You can require it with Composer, but it will not auto-register anything Laravel understands. The bundle registers workers through Symfony's container and runs them through Symfony console commands, so Laravel's console kernel and container are not wired in. It is not a drop-in replacement for an Octane driver.
- Does this bundle work with Laravel Octane?
- No. Laravel Octane uses its own worker contract and application sandbox, while this bundle targets the Symfony Kernel runtime. The two abstractions do not line up, so you cannot point Octane at this package and expect it to work. A custom Octane-style driver or a bespoke Workerman bootstrap would be required.
- How are workers defined and configured with dependency injection?
- Workers are registered as services in the Symfony container, so they can use autowiring, configuration, and PSR-3 logging like any other service. Runtime settings and worker definitions are configurable through the bundle's configuration. In a Laravel bridge you would need to reproduce that registration and configuration layer yourself.
- Which Workerman versions does luzrain/workerman-bundle support?
- Version 0.4.0 adds Workerman 5 support, which is a positive maintenance signal. However, that means the bundle now spans the Workerman 4 to 5 transition, where worker APIs, process management, and some event-loop semantics changed. Expect short-term churn and fixups while that stabilizes.
- What is the reuse_port option and is it useful for production?
- It enables SO_REUSEPORT so multiple independent master processes can bind the same listening port. That helps with zero-dropped-request deploys and multi-pool scaling without a single master becoming a bottleneck. Caveats are that it is Linux-kernel dependent, requires consistent socket options across listeners, and gives you no application-level visibility into uneven connection distribution.
- Is this bundle safe for long-running Laravel or Symfony workers in production?
- For Symfony it is the intended design, but adoption evidence is thin: roughly 29 stars, zero dependents, and effectively a single maintainer. There is no production track record to borrow, and the new Workerman 5 path has little field exposure. Treat behaviors as unverified until you have tested them in your own environment.
- What are the alternatives for running Workerman-style workers in Laravel?
- Laravel Octane already supports Swoole, RoadRunner, and FrankenPHP with first-party drivers and tooling. If you specifically need pure PHP without a C extension, Windows support, or a socket and long-connection tier, using Workerman directly or projects like webman and GatewayWorker is often a better fit. This bundle is most useful when you want Symfony DI around Workerman, not Laravel integration.
- How much work is it to bridge this bundle into a Laravel codebase?
- Plan for roughly one to two engineer-weeks for a spike plus a hardened bridge, and assume ongoing ownership. You would need a custom Octane-style driver or a Workerman bootstrap that constructs Laravel's Application, converts requests, and manages the sandboxed container lifecycle. That bridge is the real deliverable, not the package.
- What maintenance and support risks should I expect from luzrain/workerman-bundle?
- The project is effectively single-maintainer, and coupling to internal Workerman APIs means upstream changes can break you without a security or deprecation notice. You also inherit failure opacity: forked-worker problems can produce non-obvious symptoms, and there is no Octane-style status command or Telescope integration to lean on. Budget for observability and upgrade churn rather than expecting first-party support.