Laravel S Laravel Package

Product Decisions This Supports

• Runtime strategy, not a feature decision. LaravelS answers "how is Laravel served?" — resident Swoole/OpenSwoole workers that boot the framework once per worker instead of per request. It is the lever behind throughput-per-core and p95/p99 latency targets, so the decision belongs in platform/architecture review, not a product backlog.
• Build vs. buy on performance. The alternative to adopting LaravelS is one of: horizontal scaling of PHP-FPM (ongoing cloud cost), hand-rolling a Swoole bootstrap plus process supervisor (build and maintenance burden), or a service rewrite. Evaluate LaravelS as the "buy" option against those three — not against doing nothing.
• Roadmap unblocks. Because it ships Swoole's async primitives, it turns several would-be projects into configuration work: WebSocket/long-lived connection endpoints, in-process timers replacing small cron fleets, async task workers replacing lightweight queue consumers, and coroutine-based concurrent outbound I/O. Scope these as bundled capability gains when justifying the pilot.
• Capacity and unit economics. The resident-worker model changes instance sizing: fewer instances for the same RPS, higher per-instance memory, and a scaling curve driven by worker count rather than process spawn rate. This feeds cloud-spend forecasts and headroom planning.
• Use-case fit. Strongest for high-traffic JSON APIs, internal services with spiky load, and real-time features. Weak fit for low-traffic admin panels, where the operational overhead buys nothing measurable.

When to Consider This Package

Adopt when:

• You have an existing Laravel/Lumen application (roughly the 5.x–10.x era) that is CPU-bound on framework bootstrap and PHP-FPM scaling is a visible cost line.
• You can install and operate the swoole/openswoole PHP extension — containers, VMs, or on-prem hardware you control. Not viable on most managed or serverless PHP platforms.
• The team accepts the resident-worker contract: nothing is per-request unless you make it so. Budget explicit time for auditing singletons, static properties, $GLOBALS, config mutations, and package compatibility, plus regression tests that exercise repeated requests in one worker.
• You want WebSocket, timers, and task workers from a single dependency rather than stitching three together.
• You treat active maintenance as a risk input: the v3.8.8 release is a hygiene fix (a return type on configure()), but it confirms the project is still receiving attention.

Look elsewhere when:

• Greenfield projects → Laravel Octane. It is first-class and vendor-maintained, supports Swoole, RoadRunner, and FrankenPHP, and gives an exit ramp if Swoole operations prove painful. LaravelS's remaining advantages are legacy-app compatibility and its bundled extras; for new builds, Octane is the lower-risk default and the comparison should be written into any adoption memo.
• The dependency tree assumes fresh-process semantics (global state, static caches, direct $_SERVER/$_SESSION reads). Migration cost can exceed the performance win.
• No one on the team can debug a long-lived worker — memory creep, stale database connections, coroutine-context bugs. The failure mode is slow-burning and subtle, not a clean crash.
• You require a commercial vendor SLA for your runtime.

Upgrade note for v3.8.8: the release adds a return type to configure(). Normally a safe patch bump, but any code subclassing LaravelS classes and overriding configure() without a compatible return type will fatal. One grep for function configure( before rollout clears it.

How to Pitch It (Stakeholders)

For executives: This is a cost-and-latency play, not a customer-facing feature. Serving Laravel from resident Swoole workers instead of PHP-FPM typically reduces the compute needed for a given traffic level, because the framework boots once per worker rather than once per request. It also lets us ship real-time endpoints and background processing without standing up additional services. The trade is operational: long-lived workers demand engineering discipline around request isolation. Recommendation is a bounded pilot on one high-traffic service with a measured before/after on latency and instance count — not a fleet-wide mandate.

For engineering: LaravelS keeps the application in memory across requests and provides coroutine I/O, task workers, timers, and WebSocket support in one dependency. The adoption cost is real and mostly cultural: controllers and services must be stateless by construction, per-request resets go through CleanerInterface, cross-worker shared state goes through Swoole\Table, and any blocking call — sleep(), synchronous HTTP, heavy CPU — stalls every concurrent user on that worker. Plan for max_request tuning to bound memory growth, reload versus restart discipline in the deploy script, nginx in front for TLS and static assets, and supervisor/systemd around bin/laravels start -d. The v3.8.8 change is a return-type declaration on configure(); safe as a patch bump unless we override that method anywhere.