Webman Framework Laravel Package

Product Decisions This Supports

• Runtime and architecture selection for concurrency-bound services. webman is a resident-memory, event-loop PHP framework built on Workerman. It informs the decision of whether a given service should run on PHP-FPM + Laravel or on a long-running worker runtime — HTTP APIs, WebSocket/SSE gateways, IoT fan-out, push/notification hubs, internal RPC, and always-on queue consumers.
• Build vs. buy for a worker runtime. The alternative is hand-rolling process management, reloading, routing, middleware, and connection handling on raw Workerman or ReactPHP. Adopting the framework converts weeks of undifferentiated plumbing into a Composer dependency with an upgrade path.
• Estate segmentation, not platform migration. The realistic roadmap outcome is a two-runtime portfolio: Laravel for CRUD/product velocity, webman for the handful of endpoints where bootstrapping and per-request memory teardown dominate cost. This decision determines hiring, on-call, and deployment tooling scope.
• Buy/standardize decision against Laravel Octane. Octane (Swoole, RoadRunner, FrankenPHP) is the incumbent option. webman is only justified where Octane's Laravel boot cost, its worker model, or its WebSocket story is a poor fit — otherwise Octane wins on reversibility.
• Cost and capacity planning. Fewer instances for the same QPS changes the infra line item and the autoscaling story; that number is what funds or kills the pilot.
• Use-case triage for the next 2–3 quarters. Concrete candidates worth scoring: WebSocket notification service, high-QPS read-only catalog/feature-flag endpoints, device telemetry ingest, webhook receivers needing high connection counts, and cron/daemon replacements.

When to Consider This Package

Consider it when:

• The team is already PHP-native and the concurrency problem is real and measured — connection counts, p95 latency, or per-request bootstrap cost that PHP-FPM cannot fix.
• The workload is I/O-bound with many idle connections (WebSockets, SSE, long-poll, upstream fan-out) rather than CPU-bound.
• You can commit to Linux, a long-running process model, and the operational discipline it implies: no shared state between requests, no blocking calls, memory-growth monitoring, graceful reload.
• You want a thin, Composer-installable core you can wrap in your own conventions rather than a full opinionated ecosystem.
• You are willing to run a benchmark proof-of-concept on your own traffic before committing — mandatory here given the thin public signal.

Look elsewhere when:

• You need Laravel's first-party ecosystem (Sanctum, Cashier, Nova, queues, Forge/Vapor) or the breadth of English-language docs, Stack Overflow coverage, and hiring pool. Laravel Octane gets most of the throughput benefit with near-zero migration and is the reversible default.
• The team cannot own a resident-memory runtime — state leaks and blocking I/O become production incidents, not code review comments.
• Deployment constraints forbid long-running custom processes (shared hosting, restrictive FaaS/PaaS, Windows).
• Latency is database- or upstream-bound; a faster runtime buys nothing.
• The public signals are unconvincing after diligence: 148 stars and 0 dependents are weak on their own, and a release dated 2026-08-24 is a data-hygiene red flag. Verify against the umbrella walkor/webman distribution, the actual release history, security-response record, and named production references in your region. If you cannot find two credible production users, treat it as unproven.

How to Pitch It (Stakeholders)

To executives: This is a cost-and-capacity lever, not a platform migration. For a narrow class of services — persistent connections and high-request-rate APIs — a resident-memory PHP runtime can serve the same traffic with materially fewer instances, in a language we already staff. The proposal is a bounded pilot on one non-critical service with a hard kill criterion, not a rewrite of the product.

To engineering: webman gives us a worker-based runtime with familiar PSR-7/PSR-15 middleware, routing, and a plugin model for DB, Redis, and queues. The trade is explicit: we gain throughput and connection density, and we take on responsibility for process lifecycle, memory hygiene, and non-blocking I/O discipline. A Laravel developer is productive in one to two sprints; the risk is not learning curve, it is the class of bugs that only appear after six hours of uptime.

Risk framing to state plainly: the package's standalone adoption metrics are thin, and the release metadata looks anomalous. That is a diligence task, not a veto — but it means we validate against the parent project and real deployments before any commitment beyond the pilot. Keeping Laravel Octane as the pre-agreed fallback makes the whole decision reversible, which is the strongest argument for approving it.

The ask: two engineers, three to four weeks, one service (WebSocket notifications is the cleanest candidate). Success criteria defined up front: p95 latency, cost per 1,000 requests versus the current baseline, and a written operational runbook covering reload, memory monitoring, and rollback to the existing stack.