Yii Runner Laravel Package

Product Decisions This Supports

• Runtime portability roadmap. yii-runner exists to separate application bootstrap from how the process is invoked — a single runner contract with implementations for classic PHP-FPM, console, and long-running worker runtimes (RoadRunner, Swoole). This is the exact decision surface for any "do we move to persistent workers?" initiative, and the package is a working reference architecture for it.
• Build vs. buy for bootstrap/entrypoint code. If your product is a framework or platform with multiple deployment topologies (CLI, HTTP, queue worker, serverless), this is a template for what that layer should look like: thin, dependency-injected, one adapter per runtime. Buy is not available to you — see below — so this is a build-with-reference input, not a procurement line item.
• Scoping an Octane/FrankenPHP migration. The package's decomposition maps almost one-to-one onto Laravel Octane's worker lifecycle concerns (boot once, handle many, reset state between requests). Use it to sanity-check your own migration design: what is per-process vs. per-request, where does the emitter live, how is the app torn down.
• Framework-adjacent tooling features. If you ship a CLI/SDK that must run under both request-per-process and worker models, the runner abstraction is a cheap, well-bounded pattern to adopt conceptually in your own codebase.
• Explicit non-decision: do not add a dependency. This is a Yii package, not Laravel. It is not installable-into-Laravel in any meaningful way, has 17 stars and zero dependents, and is published by the framework's own org for its own ecosystem. There is no product decision here that involves pulling it in.

When to Consider This Package

Consider reading (not installing) it when:

• You are designing a runtime-agnostic entrypoint for a PHP application and want a small, BSD-3-licensed reference for the interface boundary between "bootstrap the app" and "run the loop."
• You are evaluating persistent-worker deployment (RoadRunner, Swoole, FrankenPHP worker mode) and need to articulate to engineering where the state-leak risks live.
• You own a framework/foundation team and are standardizing how multiple runtimes are supported without forking bootstrap code per runtime.

Look elsewhere — decisively — when:

• You are on Laravel. Octane already owns this problem, is maintained, and has orders of magnitude more usage. Adopting yii-runner in a Laravel app is not viable; it targets Yii's application/DI contracts.
• You need production-proven infrastructure. 17 stars and 0 dependents means essentially no external validation, no third-party battle-testing, and a single-maintainer (org-level) bus factor. That is acceptable for a framework's internal component; it is not acceptable as a dependency in someone else's critical path.
• You need it to be a stable platform contract. Despite an active release (2025-12-19), the API is scoped to Yii's needs and carries no compatibility promise to outsiders.
• The problem is already solved by your framework or by a platform runtime (Octane, FrankenPHP's own worker bootstrap, a custom public/index.php).

Net: evaluate as a design reference, reject as a dependency.

How to Pitch It (Stakeholders)

For executives (30 seconds): We looked at yii-runner, a small open-source component from the Yii framework team that standardizes how a PHP app starts up across different execution models — traditional web requests, command line, and modern always-on worker processes. Recommendation: do not adopt it. It's built for a different framework (Yii, not ours), has negligible adoption (17 stars, 0 downstream users), and solves a problem our stack already solves. It is useful to us only as a free, permissively licensed reference design — which we can study at zero cost and zero risk.

For engineering: The valuable idea is the seam it draws: an application runner interface with one adapter per runtime, so bootstrap, request handling, and process lifecycle stay decoupled. That's directly relevant to our Octane/worker-mode work — particularly the per-process-vs-per-request state question, which is where these migrations usually break. Action: one engineer spends half a day reading the runner and worker-mode adapters and writes up the state-lifecycle model; we apply the pattern in our own bootstrap and take no new dependency. License is BSD-3, so even direct code reuse of small snippets is permissible, though I'd prefer we reimplement rather than vendor from an unmaintained-by-our-standards project.

Risk statement: Low. No dependency added, no procurement, no vendor relationship. The only cost is a few hours of engineering reading time, and the only risk is over-indexing on a low-adoption codebase — mitigated by treating it as a pattern source rather than a library.