Runtime Laravel Package

Product Decisions This Supports

• Runtime portability roadmap calls. The component is the seam that lets the same application code boot under PHP-FPM, CLI, long-running workers (RoadRunner, FrankenPHP worker mode, Swoole), and serverless handlers. If a roadmap item reads "run our Laravel services on a worker runtime to cut per-request bootstrap cost," this package is a legitimate input to that evaluation — but as one dependency of the decision, not the decision itself.
• Build vs. buy on bootstrap glue. Every team that supports more than one SAPI eventually writes a bespoke public/index.php and a parallel CLI entrypoint. Symfony Runtime is a maintained, MIT-licensed answer to that. The PM question is whether we accept an external convention (with Symfony's BC policy behind it) or keep owning ~100 lines of glue. For most teams the glue is cheap; for teams running three or more SAPIs it stops being cheap.
• Security posture on argv/$_SERVER handling. The release history shows two consecutive CVEs in this exact area (CVE-2024-50340, and CVE-2026-46626 patching a bypass of it), with fixes backported to 5.4, 6.4, 7.x and 8.x branches. That is a genuine signal: if we consume or hand-roll this kind of bootstrapping, we now have a concrete, named class of vulnerability to track and a vendor that has consistently shipped patches across five major lines.
• Standalone CLI/tooling investments. If we ship internal Symfony-component console tools or PHP CLIs outside the Laravel HTTP stack, Runtime is a low-cost way to get consistent env/dotenv/project-dir handling (APP_PROJECT_DIR, APP_RUNTIME, extra dot-env files) without inventing a config convention.
• Dependency inventory and upgrade planning. It is a Symfony split package with a fast release cadence and PHP-version coupling (8.x requires PHP ≥ 8.4). That drives a real decision: which PHP floor we commit to, and whether our platform stays inside Symfony's supported matrix.

When to Consider This Package

Consider it when:

• The application must boot under more than two SAPIs and we are currently maintaining divergent entrypoints.
• We are evaluating FrankenPHP, RoadRunner, or serverless (Bref/Lambda) and want the bootstrap layer to be a supported dependency rather than custom code — note that 7.4+/8.x adds automatic FrankenPHP worker-mode detection and configurable project_dir.
• We are building standalone Symfony-component tooling that needs dotenv/env/runtime abstraction.
• We want a maintained, security-patched implementation of argv/$_SERVER gating rather than our own.
• Global-state leakage is a measured problem — flaky integration tests, cross-request env bleed under workers — and we want a standard seam to fix it.

Look elsewhere or skip it when:

• The target is a conventional Laravel HTTP application. Laravel owns its bootstrap (Illuminate\Foundation\Http\Kernel, bootstrap/app.php) and does not use this component. Adding it directly buys a shim with no consumers.
• Laravel Octane already answers the worker-runtime question for us (RoadRunner/FrankenPHP/Swoole integration, request sandboxing, warm workers). In that case the incremental value is near zero and we would be layering two runtime abstractions.
• The motivation is "decouple from global state" as an architecture initiative. This package decouples the entrypoint; it does not stop application code from reading $_SERVER or $_ENV. That work is a codebase refactor, not a dependency install — do not let a package adoption stand in for it.
• We need PHP < 8.4 support long-term; that pins us to the 7.x line and constrains the upgrade narrative.

Also flag for the record: the "0 dependents" figure is unreliable for Symfony split packages (they are subtree-split from the monorepo), so do not treat it as evidence of low real-world usage. Conversely, the 743 stars reflect a component that is ubiquitous transitively but rarely chosen deliberately — that is exactly why it deserves a short, skeptical assessment rather than a roadmap slot.

How to Pitch It (Stakeholders)

To executives: This is not a feature investment; it is a small, cheap option on future deployment flexibility. Symfony Runtime is the piece that lets a PHP application boot identically on traditional web servers, long-running workers, and serverless platforms without rewriting its entrypoint. It is MIT-licensed, backed by a vendor with a decade-long BC and security-patch record (multiple release branches patched in parallel for the same CVE). The honest framing: adopt it only if and when we commit to a worker or serverless runtime; if we stay on Laravel Octane or PHP-FPM, the correct decision is "no action, monitor." Recommendation: no budget line, no dedicated headcount — a spike-sized evaluation scoped to whichever roadmap item actually requires runtime portability.

To engineering leadership: Three things worth knowing. First, it is a seam, not a framework — roughly "a supported way to write public/index.php that adapts to the SAPI," so the cost of adoption is hours, and the cost of not adopting it is bespoke bootstrap code and divergent entrypoints. Second, it does not solve global-state coupling in application code; if that is the stated goal, budget a refactor, not a dependency. Third, the security history is a plus, not a minus: CVE-2024-50340 (argv read on non-CLI SAPIs) and CVE-2026-46626 (a bypass of that patch) were both fixed and backported to 5.4/6.4/7.x/8.x — evidence of a responsive maintainer, and a reminder to keep this pinned and patched. Note the version coupling: 8.x requires PHP ≥ 8.4, so our PHP floor decision and this package's major version are the same decision.

To the delivery team: If we proceed, scope it as a timeboxed spike, not a migration. Validate one concrete runtime (most likely a worker behind Octane/FrankenPHP, or a Bref handler) end-to-end, measure cold-start and per-request bootstrap cost against the current setup, and confirm no conflict with Laravel's own bootstrap or Octane's sandboxing. Success criteria should be a measured number or an explicit "no measurable gain — stop." Default position for existing Laravel services remains unchanged: do not add this dependency to applications that will not actually run on an alternate runtime.