- Is workerman/webman-framework a Laravel package or a separate framework?
- Webman is a separate application kernel built on Workerman's event loop, not a library you drop into a Laravel app. It reuses standalone illuminate components such as Eloquent, validation, translation, and pagination, which is why it feels Laravel-like. Running it inside an existing Laravel application would mean booting two kernels, so treat it as its own deployable service.
- How do I install Webman with Composer?
- Webman is normally scaffolded as a project rather than required into an existing app, using Composer's create-project command for the workerman/webman skeleton. That gives you the process manager, routing, middleware, and config layout in one step. Adding workerman/webman-framework as a dependency inside a Laravel codebase is not the intended integration path.
- Does Webman support Laravel's Eloquent ORM and validation?
- Yes, Webman consumes illuminate/database for Eloquent and illuminate/validation for validators, along with translation and pagination components. These are used as standalone packages rather than through the full Laravel framework. You get familiar APIs, but facades, global helpers, and Laravel-specific service providers are not available unless you wire equivalents yourself.
- Can I install Webman inside an existing Laravel application with composer require?
- There is no credible path to composer require workerman/webman-framework inside a Laravel app and getting incremental value, because you would be booting two application kernels. The realistic integration is process-level: run Webman as a separate deployable behind the same edge gateway, sharing the database and Redis. Anything that depends on Laravel facades or the request lifecycle will not port cleanly.
- Which Laravel versions does Webman support?
- Webman is not tied to a Laravel release; it pulls individual illuminate/* packages, so compatibility depends on the version constraints in its composer.json. Check the current constraints on Packagist and the repository tags before assuming a specific Laravel version. Release metadata should be treated as unverified until confirmed against Packagist.
- How do I test a Webman application?
- Webman applications can be tested with PHPUnit like any Composer project, and handlers can often be exercised as plain classes without booting an HTTP kernel per test. Because workers stay resident, tests must reset static and global state between cases and avoid leaking open handles. Isolate anything that depends on the event loop or long-lived connections.
- What production problems should I expect with Webman's persistent workers?
- Persistent processes mean memory leaks, static or global state bleed between requests, unclosed handles, and blocking calls are not style issues; they degrade the whole worker. Synchronous cURL, blocking file I/O, and sleep calls should be replaced with async or coroutine-safe equivalents. Laravel developers used to shared-nothing PHP-FPM need to reason about this explicitly.
- How does Webman compare to Laravel Octane, Swoole, or RoadRunner?
- Webman is a full framework kernel on Workerman, while Octane keeps Laravel and swaps the runtime, and RoadRunner is a generic application server. Webman's draw is a Laravel-flavored API with lower overhead and first-class WebSocket, TCP, and SSE support, plus optional Swoole or Swow coroutines. Choose Octane if you must preserve Laravel facades and packages; choose Webman for greenfield high-concurrency services.
- Do I need Nginx or PHP-FPM to deploy Webman?
- No, Webman runs under its own process manager and does not require Nginx or PHP-FPM. Many teams still put Nginx or an API gateway in front for TLS, static files, and routing. Deployment is typically a single supervised process manager with its own Dockerfile and CI pipeline.
- Is Webman actively maintained, and what is the bus factor?
- The project is effectively one author's work, so single-maintainer concentration is a real risk regardless of star counts. The 148 stars and near-zero dependents on this repo are misleading because frameworks are consumed through project scaffolding, not as transitive dependencies. Before adopting it, confirm current release activity on Packagist and assess whether the codebase is small enough to fork and own.