Swerve Laravel Package

Product Decisions This Supports

• Serving-layer build vs. buy. Swerve is a candidate for the "how does our Laravel app actually handle HTTP in production" decision. That's a real PM decision because it touches hosting topology, deploy pipeline, observability, and on-call runbooks — not just a Composer line.
• Performance roadmap without infrastructure spend. If the roadmap has "reduce p95 latency" or "handle N× traffic" items, an async application server is an alternative lever to adding instances or re-architecting. This package belongs in that trade-off analysis, not the feature backlog.
• Concurrency-dependent features. Anything that needs long-lived connections or fan-out — SSE, streaming responses, background polling, webhook fan-in, internal APIs aggregating multiple upstreams — is materially cheaper to build on a fiber-based server than on PHP-FPM. This informs whether those features are a quarter of work or a sprint of work.
• Tech-stack consolidation conversations. Choosing an application server is a multi-year commitment. Adoption now sets the default for future services, so it should be a deliberate decision with an owner, not an incidental dependency.
• Async-runtime evaluation. Even if you don't adopt Swerve, evaluating it forces the team to answer whether phasync/Revolt/Swoole-style concurrency is on your 12-month horizon. The output is a decision memo either way.

When to Consider This Package

Consider it when:

• You have a concrete, measured problem that a long-running worker solves — FPM process overhead, connection-per-request costs, or IO-bound latency you can't fix in the database.
• You have a team comfortable with async pitfalls (shared state across requests, memory leaks in long-lived workers, request-scoped container state in Laravel). This is the single biggest determinant of success.
• The workload is IO-bound and your Laravel app is largely stateless per request; that's the sweet spot for fiber-based serving.
• It's scoped to an internal service, a pilot, or a workload with a clean rollback path to FPM. Small blast radius, real learning.
• You're willing to vendor or fork. At 14 stars with an unverified repository, you should assume you may end up owning this code.

Look elsewhere when:

• The service is revenue-critical and needs a support contract, CVE response cadence, or a named maintainer you can escalate to. FrankenPHP, RoadRunner, or Swoole have the operational track record and third-party integrations (Octane adapters, docs, hiring pool).
• You need proven, reproducible benchmarks under your workload. The adoption signal here is too thin to infer production readiness; the release date also needs verifying against the repo.
• Your team's async maturity is low and you have no capacity to build it. The failure mode isn't "slower" — it's state leaking between requests in a way that's hard to reproduce.
• You need broad ecosystem alignment: managed platform support, existing Laravel Octane drivers, observability integrations, or a hiring pool that already knows the tool.

How to Pitch It (Stakeholders)

To executives: "This is a lightweight PHP application server that could let us serve more traffic per instance and build real-time features without new infrastructure. It's early-stage — small community, unproven at scale — so I'm not proposing we standardize on it. I'm proposing a two-week spike on one non-critical internal service, with a rollback to our current setup and a written go/no-go. Cost is engineering time only; the upside is either a cheaper path to our latency targets or a well-evidenced 'no' that closes the question for a year."

To engineering: "Swerve is a fiber-based application server on phasync. The value proposition is concurrency in-process — no FPM process-per-request, no separate runtime binary, and streaming/SSE becomes straightforward. The cost is that long-lived workers change our assumptions: container state, singletons, static caches, and memory growth all need auditing. Before we commit, I want a spike that answers three things: does it survive our worst-case endpoint without leaking, what's the actual p95 delta on our traffic mix, and what does our deploy/restart story look like. If any of those is unclear, we stay on the current stack and revisit."

Framing note for both audiences: the deciding factor is not the package's feature list — it's whether the team can operate a long-running async PHP runtime safely. Lead with that, and the adoption conversation becomes an engineering-capacity question rather than a tooling argument.