Engine Laravel Package

Product Decisions This Supports

• Build vs. buy for the runtime/transport layer. psx/engine is a thin abstraction over how a PHP application is served (FPM/Apache vs. a long-running socket or CLI-driven server). The build-vs-buy question here is small in absolute terms — this is a narrow interface package, not a framework — so the decision is really "adopt a pre-existing interface contract" vs. "write ~a few hundred lines of our own adapter." That is a low-stakes, reversible decision, which is exactly the kind of thing a PM should timebox rather than debate.
• Deployment topology roadmap. If your roadmap includes running the same application codebase under more than one serving model (classic FPM for shared hosting / enterprise customers, long-running workers for high-throughput or websocket-adjacent workloads), an engine abstraction is the seam that makes that a config change instead of a rewrite. This package is a reference design for that seam.
• SDK / embeddability decisions. If you plan to ship your product as something third parties host themselves (an embeddable API layer, a self-hosted appliance), a documented engine interface lets customers plug in their own server without forking your app. That is a product-positioning decision as much as an engineering one.
• Framework-ecosystem fit. This package is meaningful primarily inside the PSX family (psx/api, psx/framework). The decision it informs is "do we standardize on the PSX stack," not "do we add one library." Treat it as a signal about ecosystem alignment, not as a standalone component choice.
• Not a differentiator. Nothing here is customer-visible. It should never appear on a roadmap slide; it belongs in architectural-debt and platform-investment conversations only.

When to Consider This Package

Consider it when all of the following hold:

• You are already building on the PSX stack, or you are deliberately evaluating PSX as your API framework — the abstraction is designed to fit that ecosystem's request/response lifecycle, not Laravel's or Symfony's.
• You have a concrete, funded requirement to support two or more server runtimes in production within the next two quarters.
• You are willing to treat the package as a reference implementation to fork or vendor, not as a dependency you expect upstream to maintain on your behalf.

Look elsewhere — or plan to write your own — when:

• You are on Laravel or Symfony. The idiomatic answers are Laravel Octane / RoadRunner / Swoole adapters or Symfony Runtime. Those have real maintainers, real docs, and real production footprints. Layering a 2-star package underneath them adds a translation layer with no payoff.
• Adoption signals matter to your risk model. Two stars and zero dependents is not a red flag so much as an absence of evidence. There is no crowd to inherit bug fixes from, no Stack Overflow corpus, and no third party who has stress-tested this in anger. For a component on the request path, that is a meaningful risk regardless of how simple the code is.
• You need vendor support, an SLA, or a security response process. Apache-2.0 gives you the legal right to fork and self-support; it gives you nothing else. Budget for that explicitly if you adopt.
• The abstraction is broader than your need. If you only ever deploy to FPM, adding a server-abstraction layer is pure carrying cost. The correct answer is to do nothing until a second runtime is actually on the roadmap.

How to Pitch It (Stakeholders)

To executives: This is a small, permissively licensed utility that lets an application run on different kinds of web servers without code changes. It is not a strategic bet and does not merit budget on its own. The relevant strategic question is whether we need multi-runtime portability at all — and if we do, this package is a useful prior-art reference that could save us a design cycle. Recommendation: fund a short engineering spike, not an adoption.

To engineering: Treat psx/engine as a design template, not a dependency. It is a thin adapter interface in the PSX ecosystem, Apache-2.0, with negligible adoption — two stars, zero dependents — so assume you own the code the moment you pull it in. The right move is a one-to-two day spike: read the interface, compare it against Laravel Octane / Symfony Runtime / RoadRunner, and decide whether to vendor it, fork it, or write a smaller interface scoped to our actual runtimes. If we are not on PSX and not shipping a self-hosted product, the expected outcome of that spike is "no action" — and that is a successful result.

Bottom line: low cost, low risk, low urgency, low signal. Keep it on the watchlist; revisit only when a second server runtime becomes a committed requirement.