Webman Laravel Package

Product Decisions This Supports

• Runtime modernization vs. horizontal scaling. The core decision this informs is: when throughput or p95 latency becomes a roadmap constraint, do we buy more servers/PHP-FPM workers, or change the execution model? Webman's resident-process design removes per-request framework bootstrap, so it's the "change the model" option on that fork — and it's the one with a measurable cost-per-request delta you can put in a business case.
• Service consolidation. Webman runs HTTP, WebSocket, TCP/UDP services, cron, and queue consumers in one process model. That supports a real architectural decision: collapse a separate Node/Go realtime service or a sidecar scheduler into the PHP deployable, reducing the number of runtimes, deploy pipelines, and on-call surfaces the team owns.
• Realtime feature roadmap gating. Chat, presence, live notifications, SSE dashboards, IoT/MQTT ingest, and long-poll endpoints are cheap to greenlight here rather than "that's a different team's stack." If realtime is on the 2–3 quarter horizon, this reframes it from a new-platform bet to an incremental feature.
• Build vs. buy on the async layer. The alternatives are: build directly on Workerman (more control, more plumbing), adopt Swoole/RoadRunner (C extension / separate binary in the ops path), or pay for a managed runtime. Webman is the "buy, pure-PHP, MIT" middle path — same language and package manager, no new system dependency.
• Migration sequencing. Because webman exposes Laravel's illuminate/* components (database, Eloquent, validation) it supports a staged decision: move new and stateless services first, leave the monolith on FPM, and only then decide whether the monolith ever moves. That de-risks the roadmap by making the bet reversible per service.
• Hiring and maintenance budget. It supports a "stay in PHP" decision when the alternative on the table is rewriting hot paths in another language; that's a headcount and time-to-hire question as much as a performance one.

When to Consider This Package

Adopt when:

• You have a PHP team and measurable evidence that framework bootstrap / per-request overhead is a top-3 contributor to latency or infra cost — not a guess, a profile.
• Long-lived connections (WebSocket, SSE, MQTT, TCP) are on the roadmap and you don't want to stand up a second stack for them.
• Ops can supervise long-running processes (systemd, Supervisor, Kubernetes) but cannot easily add C extensions or sidecar binaries — the pure-PHP story is a genuine advantage over Swoole/RoadRunner here.
• The candidate services are greenfield or cleanly bounded and stateless, with no reliance on per-request global isolation.
• You're willing to enforce resident-memory discipline in code review: no mutable statics, no request-scoped data in globals, explicit cleanup, leak testing in CI.

Look elsewhere when:

• You have a large, deeply Laravel-coupled application. Laravel Octane (Swoole, RoadRunner, or FrankenPHP) gives you most of the performance win without abandoning the framework contract; migrating off Laravel is a much bigger decision than a performance decision.
• Traffic is modest and FPM is not the bottleneck. The migration cost will never amortize; fix the actual bottleneck (queries, N+1s, cache misses, external calls) first.
• You need vendor support, an SLA, commercial indemnity, or first-class APM/observability integrations. This is a community MIT project — plan for self-support.
• Your platform is a managed PaaS or shared host that assumes PHP-FPM. The deploy model changes materially.
• The team has no experience with event loops and blocking-IO pitfalls. A single blocking call stalls the whole worker; that's an incident class, not a code style preference.
• You rely on third-party packages that assume shared-nothing request lifecycles — audit these before committing.
• Ecosystem signal is thin. ~2.7k stars against Laravel's tens of thousands, and a dependent count near zero, means you should not make it a platform-wide standard without a timeboxed spike. Treat it as a tactical lever on specific services, not a strategic default.

How to Pitch It (Stakeholders)

To executives: This is a cost-and-latency lever, not a rewrite. Webman is an MIT-licensed PHP framework that keeps processes warm between requests instead of rebuilding the application on every hit — the same idea as Laravel Octane, but with no additional system dependency to install and operate. It lets one PHP deployable serve HTTP APIs, WebSocket connections, scheduled jobs, and queue consumers, which means fewer moving parts and fewer runtimes for the team to own. It stays inside our existing language, package manager, and hiring pool.

To engineering: You get a Laravel-adjacent developer experience — illuminate/database, Eloquent, and validation are usable — on top of a Workerman event loop, with a plugin ecosystem and console tooling. One process model covers HTTP, WebSocket, TCP/UDP, cron, and queues. The trade-offs are real and we should name them up front: resident memory means no shared-nothing safety net, so static and global state must be treated as a defect; blocking calls must be eliminated from request paths; and third-party packages need auditing for FPM assumptions.

How to de-risk the ask: Propose a two-to-three week spike, not an adoption. Port one real, representative endpoint, benchmark it against the current FPM baseline on identical hardware, run a soak test for memory growth, and set explicit go/no-go thresholds (throughput gain, p95 delta, memory stability, migration effort). If the numbers don't clear the bar, we've spent two weeks and learned something useful about our actual bottleneck. If they do, we have a per-service migration path that doesn't commit the monolith — and a fallback to Laravel Octane if the ecosystem risk proves uncomfortable at scale.