Horizon Laravel Package

Product Decisions This Supports

• Queue observability as a roadmap item. This is a Flarum extension that mounts the Laravel Horizon dashboard inside the Flarum admin panel — it decides whether "operational visibility for self-hosted forums" is a product surface you own or an ops runbook you hand to customers. It is infrastructure tooling, not a user-facing feature, so it belongs in a reliability/support track rather than the customer roadmap.
• Build vs. buy (vs. fork). The real decision is whether to standardize on Horizon for queue monitoring; this package is only the glue that wires Horizon into Flarum's auth and admin routing. At 2 stars, 0 dependents, and a single 2024-05 release, treat it as a reference implementation to evaluate or vendor — not a dependency to adopt on faith.
• Support-cost reduction. Failed email, notification, and digest jobs today require SSH plus artisan to triage. Embedding the dashboard for admins reduces escalation volume to engineering and shortens time-to-recovery on queue incidents.
• Hosting tier design. Informs whether you offer a managed/hosted Flarum tier that requires Redis queues and supervised workers — Horizon visibility is close to table stakes for any tier with an SLA.
• Extension portfolio curation. If you ship a distribution or marketplace of Flarum extensions, the maintenance signals here (single release, negligible adoption, score 0.27) argue for an internal fork under your own release cadence rather than listing it as a curated third-party dependency.
• Explicitly not supported: end-user features, onboarding, or anything a forum member sees. Do not sequence this against product-facing work.

When to Consider This Package

Consider it (or a fork of it) when:

• You run Flarum in production with the Redis queue driver and non-trivial job volume — emails, digests, notifications, webhooks.
• You already want Horizon and need the dashboard reachable by admins who don't have SSH, using Flarum's existing permission model instead of a bespoke route and gate.
• You can pin the 2024-05 release and absorb upgrades yourself; the code surface is small enough to audit in an afternoon.
• You have someone who can verify the authorization/gate wiring before queue payloads become visible in an admin UI.

Look elsewhere when:

• The forum is small or single-server on the sync or database queue driver — Horizon adds little beyond Flarum's built-in failed-job handling.
• Hosting is managed and you don't control Redis or worker supervision; the dashboard will be empty, misleading, or both.
• You require an actively maintained dependency. Two stars, zero dependents, and a lone release mean you must budget for a fork from day one.
• You need observability beyond Horizon's scope — alerting, tracing, cross-service correlation. Pair Horizon with Sentry/Telescope or hosted APM instead of expecting this to cover it.
• Job payloads contain data that shouldn't be rendered in a browser-accessible admin screen; confirm exposure posture first.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed admin add-on that surfaces Laravel Horizon's queue dashboard inside Flarum. It ships no customer-facing functionality; its value is reducing the engineering hours spent diagnosing stuck emails, notifications, and digest jobs, and shortening recovery when background processing stalls. License cost is zero — the real cost is ownership. Adoption is negligible (2 stars, one release in May 2024, no downstream dependents), so we should treat it as a starting point we may fork rather than a supported vendor product. Recommendation: a scoped pilot on one production forum, measured against current queue-incident resolution time, before any broader commitment.

For engineering: It's a thin Flarum extension that mounts Horizon behind Flarum's admin authorization — cheap to audit, cheap to replace, no lock-in. Before rollout, confirm Redis and supervised workers are actually in place, verify the permission gate so queue internals aren't exposed to non-admins, and pin the version. Assume we carry the fork if upstream stalls; the code footprint makes that a low-effort contingency. This is an ops-visibility decision, not an architectural one.