Laravel Async Queue Laravel Package

Product Decisions This Supports

• Shipping "background work" features without buying queue infrastructure. Transactional email, webhook fan-out, PDF/report generation, image thumbnailing, cache warming, and post-checkout side effects can all be pushed into a separate PHP process after the HTTP response returns — no Redis, no SQS, no Supervisor, no long-running queue:work daemon to operate. This moves a feature from "requires platform work" to "one config line and a job class," which is a real roadmap acceleration.
• Build vs. buy vs. defer. Teams usually face a false choice between blocking the request (bad UX, worse p95 latency) and standing up managed queue infrastructure (cost plus ops burden) for what is often a handful of short jobs. This package is the "defer" option: it keeps the queue-infrastructure workstream off the roadmap entirely for the current phase.
• Roadmap sequencing with a designed exit. Once adopted, the migration path to Redis/SQS/Horizon is a driver change, not a rewrite — same dispatch() call sites, same job classes — provided jobs are written idempotently from day one. That constraint is a product decision made now that preserves optionality later.
• Hosting and deployment cost. It materially widens viable hosting: shared hosting, single-container PaaS, small VPS, budget tiers where proc_open is available but process supervision is not. At early stage this is a direct cost lever, and it should be weighed explicitly against the ops cost of a managed broker.
• Explicitly not supported decisions. Guaranteed delivery, retry/backoff, dead-letter handling, job ordering, uniqueness, chaining/batching, rate limiting, per-job timeouts, or any job exceeding PHP max_execution_time. Treat this as best-effort async, not a durable queue. Anything with money, compliance, or "must not be lost" semantics needs a real broker, and product specs must say so.
• Sunset / exit planning (given the archived status). With the repository archived, this is best framed as a bridge, not a foundation. It supports decisions like "ship background work this quarter without platform investment, and budget the driver swap into the next infrastructure cycle." Adoption without a dated exit plan — including a named internal owner if you fork — is the wrong decision.
• Release signal (v0.8.1). The sole change is "Fix deferred service provider" — a patch resolving lazy registration of the package's service provider and queue connector so it no longer loads on every request. No public API, config, or behavior change for job authors. Read it as boot-overhead hygiene, which is the kind of unglamorous fix you want on something you depend on. It also means 0.8.0 should not be used: on that version the driver binding could fail to resolve depending on when the queue connection is first touched relative to provider boot — a real hazard under Octane, in test suites that resolve connections early, and in partially-booted console commands. Nothing here changes the product calculus, but the archive notice does.

When to Consider This Package

Consider it when most of these hold:

• The app is small-to-medium Laravel — roughly single-digit to low-tens of jobs per minute at peak (load-test before assuming) — and jobs are short: sub-30-seconds, ideally sub-5.
• You cannot or will not run Supervisor/systemd, or you're on a platform where managed queues are awkward or expensive.
• Jobs are idempotent and loss-tolerant. A dropped job degrades an experience; it does not break a contract or a ledger.
• The alternative is synchronous execution inside the request, and the resulting latency/UX cost is the actual problem being solved.
• You want the work to be fire-and-forget by design, not merely by current implementation.
• Technical fit: modern Laravel/PHP on the 0.8.x line, and your host permits proc_open / process spawning with a PHP CLI binary at a known path. Confirm this on the real production image early — many hardened hosts disable it, which kills the approach outright.
• You accept a pre-1.0, single-maintainer community package from a well-known, long-standing Laravel contributor: pin exact versions, treat upgrades as code-review events, and expect to own it (fork to internal Git) rather than rely on upstream.

Look elsewhere when any of these hold:

• You need retries, exponential backoff, dead-letter queues, job uniqueness, chaining/batching, or Horizon-style observability. The Laravel queue API exposes these; this driver does not deliver them durably.
• Jobs are long-running (large exports, video, LLM calls, bulk syncs) — you'll hit max_execution_time with no supervisor to notice or restart.
• Throughput matters, or you're multi-tenant at scale; per-job process spawn cost does not amortize, and there is no built-in concurrency governor.
• Delivery is contractually or financially material (payments, invoicing, compliance-relevant notifications).
• You're serverless or on ephemeral compute constrained by read-only filesystems or absent PHP CLI (e.g., Laravel Vapor) — failures surface at runtime, not install time.
• The org already standardizes on Redis/SQS and has the ops muscle; consistency beats convenience.
• You need a multi-year support commitment. The repo is archived and there is no vendor, no SLA, and zero dependents to lean on. If the org's policy forbids archived dependencies, that settles it.

Adoption checklist before committing: verify proc_open and CLI discovery on production and staging; pin 0.8.1 and confirm the Laravel/PHP support matrix against your deployed version; fork to an internal mirror with a named owner; add the async connection alongside the existing one rather than replacing it; ship one canary job end-to-end and measure spawn overhead and failure visibility; document the best-effort contract in the codebase so nobody later assumes retries exist; and write down the trigger condition and owner for migrating to a real broker.

How to Pitch It (Stakeholders)

To executives (the 60-second version): This is a small, low-cost dependency that lets us ship background processing — emails, webhooks, generated documents — without standing up and operating queue infrastructure. It buys faster time-to-market and keeps our hosting options open, at the price of a best-effort guarantee: work runs shortly after the user's request completes, but it isn't durably retried if the process dies. That trade is correct for our current feature set and wrong for anything financial or contractual, and we've scoped it that way. One important caveat: the project is archived upstream, so this is a deliberate bridge, not a long-term foundation. We pin the version, keep the old connection for rollback, and swap the queue driver when volume or delivery guarantees justify it — application code doesn't change, provided we hold the line on short, idempotent, side-effect-tolerant jobs.

To engineering: Adopt as the async queue driver for short, idempotent, side-effect-tolerant jobs only. Two non-negotiables: (1) every job must be safely re-runnable and safely skippable — no retries are coming to save you; (2) keep durations well under max_execution_time and payloads small. Verify proc_open and PHP CLI discovery are permitted in prod and staging before we plan around it. Pin 0.8.1 specifically — 0.8.0 has a deferred-service-provider defect that can fail to resolve the driver binding depending on boot order, and that class of bug hides under Octane, early connection resolution in tests, and partial-boot console commands. v0.8.1 is a pure patch to that registration with no API or config change, so it takes the normal upgrade cadence. Mirror the tag to internal Git so we own it rather than depend on an archived repo. Also verify queue:restart, queue:retry, and queue:failed behave sensibly — operator muscle memory won't transfer cleanly, and failed-job visibility is limited to what the backing store and failed_jobs table expose.

To the product team: You can now write "this happens in the background" into acceptance criteria for non-critical, short-running side effects. Anything where "it must happen exactly once, eventually" appears in the requirements is out of scope — flag it and we'll route it to a real broker. Because the upstream project is archived, treat this as a capacity we're borrowing, not building on: assume the package will not receive fixes, so keep the surface area small and the exit cheap. Instrument the two failure modes that matter — a dispatch that silently spawns nothing, and a spawned process that dies mid-job — and alert on queue-depth versus processed-count divergence, because dispatch will look successful either way.