- How do I install LaravelS in an existing Laravel or Lumen application?
- Run composer require hhxsv5/laravel-s, then php artisan laravels publish to generate config/laravels.php and the bin/laravels binary, and finally php bin/laravels start. The package is auto-discovered, so no manual service provider registration is needed. The host must have PHP 7.2 or newer and the Swoole or OpenSwoole extension installed and compiled. In production you typically put nginx in front as a reverse proxy to the Swoole listener.
- Which Laravel, Lumen, and PHP versions does LaravelS support?
- LaravelS targets the Laravel 5.x through 10.x era as well as Lumen, and requires PHP 7.2 or newer plus the Swoole extension. Because it relies on a native PHP extension and long-lived worker processes, your platform must allow extension installation and persistent processes. Check that the current release branch explicitly supports your framework version before adopting it.
- What is the difference between LaravelS and Laravel Octane?
- Octane is maintained by the Laravel team and supports multiple application servers, including RoadRunner and FrankenPHP, which gives you an exit ramp if Swoole does not fit your environment. LaravelS bundles HTTP, WebSocket, TCP and UDP servers plus async task workers, timers and coroutine connection pooling, and that bundled capability set is its strongest differentiator. For a greenfield project that only needs HTTP performance, Octane is usually the safer default; pick LaravelS when you actually need the extra server types or async tasks.
- Why does my LaravelS application leak data or user state between requests?
- Under LaravelS the framework boots once per worker and is reused, so singletons, static properties, $GLOBALS, mutated config values, Auth guard state and locale settings all persist across requests. If a container singleton caches per-user data, that data can bleed into a different user's response. This is usually invisible in a short smoke test and only appears under production traffic as intermittent, hard-to-reproduce corruption.
- How do I reset state between requests in LaravelS?
- Implement CleanerInterface on the classes that hold per-request state and register them so they are cleaned between requests. Beyond that, avoid mutable singleton state, prefer request-scoped services, and explicitly reset config, locale, auth and static caches you modify. Remember that CleanerInterface is a manual mitigation, not a safety net: it only resets what an engineer remembered to register.
- Why do I get MySQL server has gone away errors with LaravelS?
- Long-lived workers keep database and cache connections open far longer than PHP-FPM does, so they can exceed server-side timeouts and go stale. Common mitigations are recycling workers with max_request, calling DB::reconnect(), and using coroutine-aware connection pooling. Watch for this especially after idle periods, and monitor connection health rather than assuming a successful boot means a healthy pool.
- Can I run LaravelS on shared hosting, managed PHP platforms, or serverless?
- Realistically no. LaravelS needs the Swoole or OpenSwoole native extension compiled into PHP and a long-running process that stays resident between requests. Shared hosting, most managed PHP platforms and serverless runtimes cannot satisfy both requirements. It fits best where you control your own container images or VM fleet and can change the deployment topology.
- Does LaravelS support WebSocket, TCP/UDP servers, and async tasks?
- Yes, LaravelS has built-in support for HTTP, WebSocket, TCP and UDP servers, along with async task workers, timers and coroutine connection pooling. It also stays compatible with Laravel queues, events and scheduled tasks. These bundled capabilities are the main reason to choose it over an HTTP-only performance adapter.
- Why don't dd(), dump(), echo, header(), and setcookie() work correctly under LaravelS?
- With a resident worker there is no per-request PHP-FPM response lifecycle, so echo, dd(), dump(), header(), setcookie() and output buffering write to worker stdout instead of the HTTP response, or fail silently. This degrades incident response and raises the on-call skill floor, so use logging and proper response objects instead. Blocking calls such as synchronous outbound HTTP requests also stall the entire worker, turning a localized latency issue into a throughput cliff for every user assigned to it.
- How do I deploy LaravelS with zero downtime, and what should I check before upgrading?
- Start workers with php bin/laravels start, use php bin/laravels reload for graceful zero-downtime restarts behind an nginx upstream, and supervise processes with the bundled commands or a process manager. Before bumping the package, grep your custom handlers, tables, tasks and server extensions for configure() overrides, because v3.8.8 adds a return type declaration that will fatal any subclass lacking a compatible signature. Keep PHP-FPM in your deployment configuration as a documented rollback path if the pilot fails.