Laravel Swoole Laravel Package

Product Decisions This Supports

• Infrastructure cost & capacity planning: laravel-swoole keeps the Laravel application bootstrapped in memory inside a Swoole/OpenSwoole worker and serves requests through coroutines, which typically translates into materially higher throughput per instance and lower latency than PHP-FPM. That is a direct lever on hosting spend and on whether the next growth milestone requires a re-architecture or just a config change.
• Roadmap: framework upgrade sequencing: v2.13.0 adds Laravel 10.x support. If the product roadmap includes a Laravel 9 → 10 upgrade, this release is the gate that makes the runtime layer compatible; without it, the upgrade either blocks or forces a runtime swap. Treat it as a dependency in the upgrade epic, not a standalone item.
• Build vs buy vs adopt (runtime layer): The realistic options are PHP-FPM (status quo), this package, Laravel Octane (first-party, supports Swoole/RoadRunner/FrankenPHP), or RoadRunner directly. This release keeps the package viable as a "buy/adopt" option rather than forcing a custom build or an early Octane migration.
• Feature enablement for latency-sensitive surfaces: Real-time endpoints, high-fan-out APIs, websocket-adjacent features, and queue-heavy ingestion paths are the use cases where the throughput gain is most defensible. Useful when prioritizing which surfaces get migrated first in a phased rollout.
• Risk register / tech-debt prioritization: Because the runtime is long-lived and stateful per worker, the migration forces an audit of global/static state, singleton assumptions, and package compatibility. That audit is itself a product risk item and should be scoped and budgeted, not absorbed silently by engineering.
• Vendor/maintenance health signal: A compatibility release indicates the maintainer is still tracking upstream Laravel. It is a data point for the "is this dependency safe for the next 18 months" question — but a single PR is weak evidence; pair it with commit cadence, open-issue backlog, and release lag versus Laravel's own release dates.

When to Consider This Package

Adopt when:

• Traffic is high enough that per-request bootstrap overhead is a measurable share of latency or a meaningful share of instance count — i.e. the win is quantifiable in requests/sec or dollars, not theoretical.
• The codebase is Laravel 10.x (per v2.13.0) on PHP 8.x, and the team has, or is willing to build, operational familiarity with Swoole/OpenSwoole process management, worker recycling, and coroutine-safe debugging.
• You have a staging environment where you can run realistic load tests and a soak test, because the failure modes (state bleed, memory growth across requests) do not show up in functional tests.
• You can audit third-party packages for static/global state assumptions before rollout, and you have a rollback path to PHP-FPM.

Look elsewhere when:

• You are not yet on Laravel 10 and have no near-term plan to be — this release does not help you; assess against your actual target version.
• Laravel Octance is acceptable — as a first-party runtime it usually wins on support, documentation, and long-term maintenance risk. Choosing this package over Octane needs a specific reason (existing Swoole investment, Octane limitation you've hit, migration cost).
• The application is small or traffic is modest — the throughput gain won't repay the operational complexity, the compatibility audit, or the debugging tax.
• The codebase leans heavily on legacy packages, global state, or static caches — coroutine safety becomes an open-ended remediation project with unclear scope.
• The team has no appetite for owning a non-standard runtime — this is an operational commitment, not a Composer install.
• You need long-term-support guarantees — this is community-maintained; if procurement requires vendor SLAs, that's a blocker independent of code quality.

Verification items before committing: confirm the Laravel 10 support in 2.13.0 covers your exact minor version and PHP constraint, check the Swoole/OpenSwoole extension versions supported, and review whether the release cadence has historically lagged Laravel major releases (Laravel 10 shipped well before this PR merged — quantify that lag, since it predicts your future upgrade friction).

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated laravel-swoole, a runtime that keeps our Laravel application loaded in memory and serves requests concurrently instead of starting fresh for each one. The practical effect is fewer servers to handle the same traffic and lower response times, which is a cost-and-latency story rather than a feature story. The newly released v2.13.0 adds Laravel 10 support, which keeps it compatible with our framework upgrade path. The trade-off is operational: it requires engineering discipline around shared state and a real load-testing gate, so I'd recommend it as a scoped pilot on one high-traffic service with a measured cost/latency baseline, not a platform-wide mandate. We should also compare it against Laravel Octane, the first-party equivalent, before committing — adopting the first-party option may be cheaper over a multi-year horizon even if migration effort is slightly higher today.

For engineering leads: v2.13.0 is a compatibility release — Laravel 10.x support via PR #523. No breaking changes or deprecations are indicated in the notes, so the upgrade surface is narrow. Before we treat this as our runtime, we need three answers: (1) how much of our request latency is bootstrap overhead, measured, not estimated; (2) which of our dependencies mutate static or global state, since coroutine workers reuse process memory across requests; (3) whether the maintainer's release cadence against future Laravel majors is acceptable, given this Laravel 10 support landed well after Laravel 10 itself. Propose a timeboxed spike: one service, one load test, one soak test, documented rollback to PHP-FPM.

For product/roadmap: no user-facing change results from this release. It affects delivery risk and cost assumptions on the Laravel 10 upgrade and on any capacity planning for high-traffic endpoints. Flag it as an input to the upgrade epic's sequencing and to the infrastructure budget, and treat the dependency-compatibility audit as scoped engineering work rather than free.