Weave Code
Laravel Swoole Laravel Package
swooletw/laravel-swoole
Run Laravel or Lumen on the Swoole extension for a major performance boost. This package serves your app through Swoole's high-performance HTTP server, keeping the framework bootstrapped in memory to slash per-request overhead and handle high concurrency with ease.
High performance HTTP server based on Swoole. Speed up your Laravel or Lumen applications.
Frequently asked questions about Laravel Swoole
- What is swooletw/laravel-swoole and how does it speed up Laravel?
- It is a runtime adapter that serves Laravel or Lumen applications through Swoole's high-performance HTTP server instead of the traditional PHP-FPM request lifecycle. The framework stays bootstrapped in memory across long-lived workers, so per-request bootstrap overhead is largely eliminated and concurrency handling improves. It is best suited to performance-sensitive APIs or monoliths where latency, throughput, and worker reuse actually matter.
- How do I install swooletw/laravel-swoole in a Laravel project?
- Install it with Composer, register or auto-discover the service provider, and publish the package configuration file. You then start the Swoole HTTP server command rather than serving the app through PHP-FPM. Treat it as a runtime migration rather than an ordinary dependency upgrade, and make sure the Swoole extension is installed in every environment including CI.
- Which Laravel and PHP versions does laravel-swoole support?
- The v2.13.0 release adds Laravel 10.x support, which removes a major compatibility blocker for Laravel 10 estates. The release notes do not establish Laravel 11 readiness, so confirm actual support in practice rather than relying on version claims. Pin your Laravel, PHP, and Swoole extension versions together and verify compatibility before upgrading any of them.
- Is laravel-swoole compatible with both Swoole and OpenSwoole?
- The package targets the Swoole extension, and extension and version compatibility is one of the documented secondary risks. You should confirm the exact extension flavor and version your container images use before committing. Lock compatible versions in your images and CI so local, staging, and production environments match exactly.
- How does laravel-swoole compare with Laravel Octane?
- Both keep the framework bootstrapped in long-lived workers, but Octane is first-party and may reduce operational and support risk. laravel-swoole is a community runtime package, so maintenance cadence, issue response, and bus factor should be validated. Write a short ADR comparing laravel-swoole, Octane, and staying on PHP-FPM for your specific use case before committing.
- Why do I get stale data or state leakage when running Laravel on Swoole?
- Persistent workers mean singletons, static caches, request-scoped data, and auth or session context can survive between requests, which is the primary technical risk of this package. Audit middleware, auth, session handling, file uploads, streaming, and third-party packages for long-lived-process safety. Run your full test suite under Swoole workers and pilot on a non-critical service to surface contamination before it reaches production.
- How do I run tests and CI for a Laravel app using laravel-swoole?
- Containerize local and CI environments with the required Swoole extension so tests run under the same runtime as production. Run the full test suite under Swoole workers, not only under PHP-FPM, because persistent-worker bugs will not appear otherwise. Build a containerized spike and run representative load tests before expanding beyond a pilot.
- How do I deploy and reload workers in production with laravel-swoole?
- Operations must support a different runtime model: worker lifecycle, graceful reload, memory monitoring, and extension upgrades. Provide an internal runbook and escalation path, because PHP-FPM support procedures do not transfer directly. Scale horizontally with container replicas and tune worker count per instance against CPU, memory, and database or Redis connection limits.
- Is laravel-swoole safe for production, and what failure modes should I watch?
- Production feasibility depends more on application-state hygiene and third-party package compatibility than on installation effort. Watch for memory leaks, stale singleton state, request-context contamination, worker crashes, blocking I/O, and harder debugging. Canary a non-critical service first, and only expand after runbooks, monitoring, and rollback are proven.
- Is swooletw/laravel-swoole still maintained, and how do I roll back to PHP-FPM?
- Because this is a community runtime package, validate maintainer activity, issue response, security disclosure process, and bus factor before adopting it. Pin package and extension versions, track upstream releases, and budget recurring effort for upgrades and regression testing under persistent workers. Keep the PHP-FPM deployment path intact and pilot behind a feature flag or separate deployment so rollback is a routing change, not a rebuild.
Weaver
How can I help you explore Laravel packages today?