Flarum Redis Laravel Package

Product Decisions This Supports

• Whether to invest in community as a product surface. If the Flarum forum is customer-facing (support deflection, community-led growth, docs discussion), page latency and reliability become product metrics rather than pure ops concerns. Redis-backed caching is one of the cheapest levers on that metric, and it's a prerequisite for the queue work that most community features depend on.
• Build vs. buy for infrastructure glue. This is not really a "buy" decision — it's a thin service provider that wires Flarum to illuminate/redis. The real question is "adopt ~a few hundred lines of community glue, or write and maintain the equivalent ourselves." Framing it as glue rather than a platform keeps the decision small and reversible.
• Roadmap sequencing for async features. Notification fan-out, digest emails, search indexing, and avatar/image processing all want a queue. Whether we have a queue in place is effectively a gate on which roadmap items are cheap versus expensive to build.
• Capacity planning conversations. A working cache + queue layer buys headroom before the "do we resize the database?" conversation. That's useful evidence for a 6–12 month scaling plan, and for deciding whether to spend on infrastructure or on product.
• Extension risk assessment. Flarum's ecosystem leans on third-party extensions, many of which do synchronous work. A queue lets us absorb extension-induced load without removing functionality — a product decision (keep the feature) that depends on an infrastructure decision (have a queue).
• What it does not support: it is not a managed Redis service, not a queue monitoring UI, and not a search backend. Don't let it be scoped into those conversations.

When to Consider This Package

Adopt when:

• You are running Flarum specifically. This is Flarum-specific wiring; a generic Laravel application already gets Redis cache and queue drivers from the framework and gains nothing here.
• You already operate Redis, or have a credible plan to. Adding Redis because of this package inverts the cost/benefit.
• You want cache and queue configured together, consistently, without maintaining a custom service provider across Flarum upgrades.
• You're willing to read and own the code. It's small enough to audit in an afternoon, which is the main mitigation for its maintenance profile.

Look elsewhere when:

• You're not on Flarum — use laravel/framework's Redis integration directly, plus Horizon for queue visibility.
• You need queue observability, retry inspection, or failed-job tooling as a first-class feature. Horizon is the right answer; bridging it to Flarum is custom work this package doesn't do.
• You need Redis Cluster, Sentinel, or TLS with non-trivial option coverage. Verify the config surface against your topology before committing; assume gaps.
• Traffic is small and a single server is fine. File cache and the sync queue are adequate; a new dependency is a net cost.
• You need vendor support, an SLA, or a maintenance guarantee. Fourteen stars and a small contributor base means planning for a fork, not a support contract.

How to Pitch It (Stakeholders)

To executives: This isn't a product — it's plumbing. It moves expensive work off the request path and reduces load on the primary database, which generally shows up as faster page loads and lower database spend at the same traffic. It's MIT-licensed, so there's no procurement, no contract, and no vendor relationship to manage. The risk profile is unusually favorable because it's thin and reversible: worst case we remove it and the forum still runs exactly as it does today. The ask is small and time-boxed — approve it as an operations bet with a named owner and baseline metrics, not as a strategic platform commitment.

To engineering: It's a thin Flarum service provider over illuminate/redis, so the underlying drivers are the standard predis/phpredis stack — no exotic lock-in and nothing to learn that isn't already in the Laravel ecosystem. The codebase is small, auditable, and forkable. The honest concerns: bus factor is roughly one, there's no queue dashboard included, and advanced Redis topologies may need custom configuration. Treat it as configuration we own rather than a library we depend on, assign an owner who can patch or fork it, and capture before/after numbers on page latency, database load, and job backlog so we can justify keeping it — or dropping it — at the next review.

Decision framing: Approve conditionally on three things — Redis already present or already planned, a named engineering owner comfortable forking, and baseline performance metrics captured before rollout. If any of those are missing, the correct answer is to defer rather than adopt.