Symfony Messenger Redis Laravel Package

Product Decisions This Supports

• Build vs. buy (and "buy vs. already-have"): This package exists to add a Redis transport to Symfony Messenger. Symfony shipped a first-party Redis transport (symfony/redis-messenger) in 5.3 (2021). The v0.1.8 release adds Symfony 5 support — which is precisely the window (Symfony 5.0–5.2) the native transport does not cover. So the decision this informs is unchanged: adopt vs. use the framework's built-in transport — and the answer is still the built-in one for anything on 5.3+, unless you are pinned to Symfony ≤5.2 or need a custom serialization/stream shape this adapter provides.
• Roadmap scoping for async/messaging work: If your roadmap includes background jobs, event fan-out, or worker-based processing, this package is a data point on "what does a Redis-backed message bus look like" — but it should not anchor architecture. The bus semantics (retry, failure transport, middleware) come from Messenger, not from this adapter; the adapter is ~a thin transport.
• Architecture standardization across PHP services: Relevant if you run mixed Symfony/Laravel estates and want a shared Redis stream/queue contract. Even then, the adapter choice is per-service and low-leverage; the durable decision is the envelope format and retry/DLQ policy, which this package does not define for you.
• Laravel-specific use cases: Messenger is not idiomatic in Laravel. Laravel's native queue system with the Redis driver (and Horizon for observability) already covers the same ground with first-class framework integration, jobs, batching, and failed_jobs handling. Adopting Messenger plus a third-party Redis adapter in Laravel means importing a parallel job abstraction alongside the one your team already uses — a maintenance and cognitive-load cost with no product upside. v0.1.8 does nothing to change this.
• Vendor/risk triage: v0.1.8 is the first release since Feb 2023 and contains two items: "Support Symfony 5" and dev-dependency upgrades. It is still a 0.x package, still small, still single-maintainer, with no evidence of a dependent base. Interpretation for dependency review: one maintenance commit after a ~2.5-year gap is a pulse, not a commitment — it does not establish a release cadence, a support policy, or a security-response path. Treat it as "do not put on the critical path," and timebox any spike rather than commit.

When to Consider This Package

Adopt-consideration criteria (all should hold):

• You are on Symfony (not Laravel), and specifically on a version older than 5.3 where no native Redis Messenger transport exists, or you have a documented constraint that the first-party transport cannot satisfy (e.g., a required stream/consumer-group layout or serialization format). v0.1.8 makes the 5.0–5.2 case slightly more viable than before — the package now explicitly targets Symfony 5 — but that is a narrow, shrinking window, not a reason to adopt on 5.3+.
• You have an existing Messenger-based architecture and Redis is already an approved piece of infrastructure — the adapter is additive, not a new paradigm.
• You can accept the maintenance burden yourself: assume you may need to fork or patch. The v0.1.8 changelog is dev-facing (dependency bumps) and does not demonstrate production hardening, so it is not evidence you can lean on for runtime behavior on your PHP/Symfony combination. Confirm the license (MIT — fine) and that the code is small enough to own.
• You've validated behavior against your target Symfony/PHP versions with a short, timeboxed spike including a failure/retry path and a poison-message test. Note that "Supports Symfony 5" is a claim about the transport wiring, not about Messenger's retry/DLQ semantics on your chosen minor version — test those explicitly.

Look elsewhere when:

• You're on Laravel. Use Laravel queues + Redis, or Horizon. If you genuinely need Messenger semantics (middleware, stamps, multiple buses), evaluate symfony/messenger with the native Redis transport before this package — and question the premise, since you'd be running two job systems.
• You're on Symfony ≥5.3. Use symfony/redis-messenger; it's maintained by the framework team and versioned with the framework. The new release does not close this gap — it only widens the set of old Symfony versions the adapter claims to support.
• You need operational guarantees. A single release after a ~2.5-year gap, still pre-1.0, with no visible dependent base, means no evidence of production hardening, no community-discovered edge cases, and no signal that security or compatibility fixes will land on any schedule. Anything on a revenue path, or anything needing documented SLOs, is out.
• You need managed/observable messaging. If the requirement is dashboards, DLQ tooling, or autoscaling workers, the transport choice is secondary — pick the ecosystem that gives you those (Horizon, or Symfony + a mature broker).

How to Pitch It (Stakeholders)

For executives (one line): A maintenance release landed, but it only adds support for older Symfony versions — the capability is still available for free and with framework support in modern Symfony, so our recommendation not to adopt is unchanged and still costs us nothing.

For engineering: krak/symfony-messenger-redis provides a Redis transport for Symfony Messenger under MIT. v0.1.8 adds Symfony 5 support and upgrades dev dependencies — both non-breaking, no new features, no deprecations, and still a 0.x version. It remains effectively superseded: Symfony's own symfony/redis-messenger has covered this since 5.3, and one release after a ~2.5-year gap is not a maintenance signal we can build a support plan on — dev-dependency bumps in particular tell us nothing about production runtime compatibility. Recommendation: do not add as a dependency. For Symfony services on 5.3+, use the first-party Redis transport. For Symfony 5.0–5.2 specifically, the package is now a plausible short-term bridge, but only with an explicit owner and an exit plan tied to your upgrade to 5.3+. For Laravel services, use Laravel's Redis queue driver / Horizon rather than introducing Messenger into a framework that already has an opinionated, observable job system. If a team believes there's a specific gap the native transports don't fill, ask for a written constraint and a two-day spike with the failure path tested; absent that, this is a "no" that saves us a dependency we'd end up owning.

Framing to avoid: don't position this as "rejecting a useful tool," and don't let the new release read as "it's actively maintained now." Position it as consolidating on framework-native transports, which reduces surface area, keeps version upgrades aligned, and avoids a single-maintainer package on the critical path. The cost of saying no here is near zero; the cost of saying yes is ownership.