- What is runtime/laravel and what does it do?
- runtime/laravel is a Laravel adapter for the php-runtime abstraction. It lets a Laravel application run on PSR-7/PSR-15-compatible runtimes or worker-based servers instead of only PHP-FPM, and it handles the glue code so you can serve requests and run workers with minimal configuration. Treat it as a runtime-portability layer, not a replacement for Laravel.
- How do I install runtime/laravel with Composer?
- Install it as a Composer dependency, typically with composer require runtime/laravel, and follow the README for the runtime bootstrap or entrypoint change. The package is MIT-licensed and is introduced through a small bootstrap/runtime entrypoint rather than a broad application rewrite. Pin an exact version and verify transitive dependency constraints before rolling it out.
- Which Laravel and PHP versions does runtime/laravel support?
- The public context does not list a formal support matrix, so you should confirm Laravel and PHP compatibility against the exact package version and your target runtime. Run a compatibility spike before committing, because early-stage packages can lag behind new Laravel releases. Define your own supported matrix for Laravel, PHP, runtime server, extensions, and middleware.
- Which runtime servers are officially supported and tested by runtime/laravel?
- The package is described as integrating the Runtime PHP application server with Laravel and targeting PSR-7/PSR-15-compatible runtimes or worker-based servers. The available evidence does not enumerate officially supported runtime servers or tested combinations, so ask the maintainer or inspect the source and tests. Validate your specific runtime server in a controlled pilot before production use.
- Does runtime/laravel reset Laravel application state between requests?
- Long-running runtimes introduce state-leakage risks, and the available context does not document the exact reset behavior. You must explicitly validate container bindings, singletons, request context, sessions, cookies, file uploads, streaming responses, exception handling, and terminators. Treat state reset as a testable requirement in your compatibility spike, not an assumption.
- How does runtime/laravel handle sessions, cookies, uploads, and streaming responses?
- These request/response bridging details are lifecycle edge cases that need explicit validation for any long-running runtime. The public context flags sessions, cookies, file uploads, streaming responses, middleware, and exception rendering as areas to test, but it does not document exact behavior. Include them in your security review and pilot test matrix.
- Is runtime/laravel production-ready and what are the main risks?
- It is early-stage: the assessment cites 18 stars, 0 dependents, a recent release date, and little public production validation. Primary risks include low bus factor, limited community support, undocumented lifecycle edge cases, compatibility lag with Laravel releases, and state leakage in long-running workers. Use it as an evidence-gated runtime experiment, not a platform-wide mandate, unless you accept internal ownership.
- How does runtime/laravel compare to Laravel Octane?
- runtime/laravel is a Laravel adapter for the php-runtime abstraction, while Laravel Octane is Laravel's own long-running application server integration. If your stack already uses Octane, evaluate overlap carefully because runtime/laravel may be redundant, complementary, or conflicting depending on the target runtime. Do not assume they can be combined without a spike.
- Can I fall back to PHP-FPM if runtime/laravel causes problems?
- Yes, design the integration so rollback is a configuration change rather than an application rewrite. Keep the existing PHP-FPM path available and run dual-path canaries behind an isolated runtime entrypoint. That lets you measure boot time, latency, memory growth, error rate, and worker restart behavior before expanding.
- How should I test runtime/laravel before adopting it in production?
- Start with a non-critical internal service, pin an exact package version, and run a technical spike plus source review. Benchmark against your current FPM or Octane baseline, test first- and third-party packages that rely on request lifecycle assumptions, and perform a security and lifecycle assessment. Pilot with observability, state reset checks, graceful shutdown, and a documented rollback path before expanding.