Laravel Async Laravel Package

Product Decisions This Supports

• Feature-level latency reduction without infrastructure spend. Enables a single PHP process to fan out I/O-bound work (third-party API calls, PDF/thumbnail generation, multi-source data aggregation) in parallel. This is a cheap way to hit a p95 latency target on an endpoint before committing to queue infrastructure, autoscaling, or a dedicated worker tier.
• Build vs. buy for internal concurrency helpers. It replaces a hand-rolled proc_open/fork helper that teams typically write once and maintain badly. At MIT license and a single Composer line, the build cost is effectively zero — the real decision is whether to add a dependency versus own the code, and the answer tilts toward adopting with an internal abstraction wrapper.
• Sequencing on the roadmap: "do we need queues yet?" This package is a natural gate between a monolith that does everything inline and a full queue-based architecture. It lets you ship a feature now and defer Horizon/Redis/SQS operational cost until volume, durability, or retry requirements actually justify it.
• Validating demand for durable background work. If usage grows and users start complaining about lost jobs, silent failures, or no retry on failure, that's your evidence to fund a queue migration. Instrument accordingly.
• Concrete candidate use cases to scope: parallel enrichment of a record from 3–5 external APIs; fan-out webhook delivery where loss is tolerable; batch email/push notification sends; report and export generation triggered from an admin screen; chunked CSV/import processing inside an artisan command; dashboard tiles that each hit a separate aggregate query.
• Explicit non-goals to write down: anything financial, anything requiring exactly-once semantics, anything a user expects to see a status page for, anything that must survive a deploy or a worker restart.
• Framework-version fit is now a decision input, not an afterthought. v5.0.0 adds Laravel 11 support, so the package is viable for teams on the current LTS-track framework version. If your roadmap includes a Laravel 11 upgrade in the next two quarters, this dependency no longer blocks it — but confirm the constraint bump didn't drop the version you're on today.

When to Consider This Package

Adopt when most of these are true:

• Your workload is I/O-bound, not CPU-bound. PHP's fork model gives you concurrency for waiting, not for computation.
• Execution happens in a CLI context — queue workers, artisan commands, scheduled tasks. This is the reliable deployment shape; treat php-fpm/web-request usage as unsupported-by-default and require engineering sign-off.
• Your runtime is Linux/macOS with pcntl/posix available. Windows developers and locked-down container images are a real friction point; confirm the whole team and all environments can run it before adopting.
• Tasks are idempotent, loss-tolerant, and short-lived (seconds, not minutes). There is no durable retry, no dead-letter queue, no cross-machine distribution.
• You have no queue infrastructure and no appetite to operate Redis, SQS, or Horizon for the current volume.
• You can keep the integration behind a thin internal interface (a TaskRunner contract) so the underlying library is swappable.
• Your app is on Laravel 11, or your upgrade path lands there. v5.0.0 is the first release advertising Laravel 11 support. Because it is a major version bump, treat the upgrade as a compatibility event: read the diff/composer constraints, and don't assume v4 → v5 is a drop-in on older Laravel versions.

Look elsewhere when any of these are true:

• You need durability, retries, backoff, delayed execution, or guaranteed delivery — use Laravel Queues with Redis/SQS and Horizon. This is not a substitute and should never be positioned as one.
• You need horizontal scale or cross-machine parallelism — forking scales with the box, not with your fleet.
• You need per-task observability (traces, per-job metrics, failure dashboards). A forked child is largely opaque to standard Laravel instrumentation.
• You're already on Laravel Octane — Swoole/RoadRunner concurrency primitives solve the same problem more idiomatically and without process-forking surprises.
• The team is on Windows for development, or your base image lacks pcntl.
• You require predictable memory ceilings — forked children inherit the parent's memory; unbounded fan-out on a large parent process is a footgun.
• You are pinned to an older Laravel major and cannot move. Verify whether v5 still supports your framework version before adopting; if not, you're adopting a release line that has stopped receiving compatibility work.

Risk notes to log: 154 stars, zero dependents, and a single maintainer means low ecosystem validation and bus-factor exposure. v5.0.0 is a positive maintenance signal — an outside contributor shipped the Laravel 11 bump — but one merged PR does not change the bus-factor picture. Treat it as a thin veneer over spatie/async (its underlying engine) — pin the version deliberately (note that a v4 → v5 major bump may carry framework-version constraints), wrap it, and plan the fallback of depending on spatie/async directly if maintenance stalls. Re-check upstream at the next Laravel major release; that is the moment this package either keeps pace or becomes a liability.

How to Pitch It (Stakeholders)

To executives: This is a small, free, MIT-licensed library that lets one of our PHP processes do several waiting-on-the-network things at once instead of one after another. Practically, it compresses multi-step API and report-generation features from several seconds into roughly the slowest single step, without buying new infrastructure or adding a service to operate. The latest release adds Laravel 11 support, so it stays aligned with our framework upgrade path rather than becoming a blocker to it. Cost is one dependency and roughly one sprint of engineering to integrate and instrument; risk is contained because we'll isolate it behind our own interface and can replace it. It is a latency and time-to-market lever, not an architecture change — it does not replace our queue system for anything that must not be lost.

To engineering: Adopt it as a narrow, wrapped utility for parallel I/O in CLI contexts. Concretely: define a TaskRunner interface, implement it with this package, and forbid direct facade calls outside that adapter. Constrain fan-out (cap concurrency at ~3–5), forbid nesting, and require every dispatched closure to be idempotent and self-contained (no shared mutable state, no reliance on the parent's DB transaction). Add a lint or code-review rule so it never lands in a web-request path without an explicit decision. On v5.0.0 specifically: it's a major bump whose stated change is Laravel 11 support, so diff the composer constraints and confirm our current framework version is still in range before upgrading; test the upgrade in a branch rather than folding it into an unrelated release. Instrument wall-clock time saved and job failure counts from day one — those two numbers are the business case for the eventual queue migration. Set a review date in six months against upstream activity; if releases stall, swap the adapter to spatie/async (a one-file change) rather than forking the library.

Ask: approve the dependency and one sprint of integration work, with the explicit constraint that this is scoped to latency on I/O-bound CLI work and is not a substitute for background job infrastructure.