mad-web/nova-horizon-link
A Laravel Nova package that adds a convenient link to your Laravel Horizon dashboard directly within Nova, giving developers quick access to queue monitoring, failed jobs, and metrics without leaving the admin panel.
Architecture fit. mad-web/nova-horizon-link is a presentation-layer utility for Laravel Nova that surfaces a navigation entry pointing at the Laravel Horizon dashboard. It sits entirely on the front end of the admin panel: no models, migrations, jobs, middleware, or service providers that own runtime behavior beyond menu registration. Architecturally it is a thin Nova Menu/Tool wrapper plus configuration for the Horizon route, so it does not constrain application design, queue topology, or data model in any way. Fit is therefore binary: it either matches your Nova + Horizon version pair or it is inert. It adds no new infrastructure and no new operational dependency — Horizon and Nova are already prerequisites, and both are already heavy dependencies you have made an explicit platform decision to run.
Integration feasibility. Composer install, provider auto-discovery, optional config publish, and a fixed link target. Realistic effort is measured in minutes for a developer already inside a Nova-enabled codebase. The genuinely open question is not "can we install it" but "is it cheaper than writing the twelve lines ourselves," because a Nova menu item pointing at config('horizon.path') is a trivial in-house artifact with zero supply-chain exposure. This package only earns its place if it does something non-obvious — correct handling of Horizon's path prefix, domain, and authorization-aware visibility — and that claim needs verifying against the source before adoption.
Technical risk. Low blast radius, non-trivial supply-chain profile. The package is effectively single-maintainer, near-zero-adoption (no dependents), and unversioned in the signals provided; Nova's major-version cadence (4 → 5) is a known breaker of small Nova add-ons because the tool/menu contracts and asset pipeline shift between majors. Failure is cosmetic rather than functional — a dead link or a missing menu entry — so the downside is bounded and easily reverted. The residual risks are (a) silent abandonment across the next Nova upgrade and (b) URL construction drifting from Horizon's own route/config semantics, producing a link that 404s or lands on the wrong tenant/domain in a multi-app deployment.
Key questions.
composer.json, and is the constraint a caret range or an exact pin?Horizon::auth() gate, or does it render for users who will hit a 403?/horizon, read from config('horizon.path'), or a route name — and does it handle a non-root domain or path prefix?Stack fit. Applicable only where the stack is already Laravel + Nova + Horizon on Redis queues. If Horizon is not deployed — for example, queues are SQS-driven or monitored through an APM — the package has no consumer and should be rejected at triage rather than evaluated. Confirming the target environment is a five-minute check and should precede any deeper review.
Migration path. No migration in the data sense. Adoption is: add the dependency in a feature branch, publish and review the config, register the menu entry in the relevant Nova panel, then validate the generated URL against each environment (local, staging, production, and any multi-tenant or subdirectory deployment). The credible alternative is to skip the dependency and implement the menu item in-house; both paths take under an hour, so the decision should be made on supply-chain policy, not effort. Recommend an explicit build-vs-buy call documented in the ADR, because "we pulled a one-maintainer package to render an anchor tag" is a question that will be asked later.
Compatibility. The gating constraint is the Nova major version. Pin the dependency to the Nova major in use and add a lockfile diff to the PR so an unrelated composer update cannot silently cross a Nova boundary. Verify that the config's URL resolution matches the horizon.php config on every environment, particularly where path or the app domain differs between staging and production.
Sequencing. (1) Confirm Nova/Horizon versions and that Horizon is deployed everywhere Nova is. (2) Timebox a source read — under an hour — focused on URL construction and authorization visibility. (3) Decide build-vs-buy. (4) If adopting, ship to a non-production panel first and have an operator without Horizon authorization confirm the link is either hidden or lands on a clean 403 rather than an error page. (5) Roll to production behind the standard release, with the removal commit prepared as the rollback.
Maintenance. This is the dominant cost and it is not the code — it is the attention. A tiny package still consumes a line in the dependency inventory, appears in every security and license scan, and generates an upgrade ticket at each Nova major. The correct mitigation is either to vendor the logic into first-party code (removing the dependency entirely) or to accept a standing policy that this package is pinned and reviewed at Nova upgrade time by name. Given the triviality of the functionality, in-housing is the lower-lifetime-cost option and should be the default recommendation unless the source read reveals meaningful logic.
Support. No vendor SLA, no support contract, community issues only. Acceptable here precisely because the failure mode is a broken hyperlink, not data loss or an outage. Nothing in a runbook should depend on this package; on-call should never be paged for it.
Scaling. Negligible. The package contributes a rendered anchor and, if it ships assets, a small static bundle. It adds no queries, no queue work, no per-request backend cost that scales with traffic. It does not interact with Horizon's own polling or Redis load. There is no scaling consideration beyond Nova's existing asset pipeline.
Failure modes. (1) Nova upgrade breaks the menu registration and the link silently disappears — monitor via a smoke check or the release checklist, not alerting. (2) Horizon route or path config changes and the link 404s. (3) Users without Horizon authorization see a link that 403s, generating support noise; the fix is gate-aware visibility. (4) Package abandonment means the fix on a future Nova upgrade is either a fork or, more sensibly, replacing it with the in-house menu item. (5) In multi-tenant or multi-domain deployments, a hard-coded or single-host URL points at the wrong application. All five are cosmetic or navigational; none affect queue processing, data integrity, or availability.
Ramp-up. Effectively zero for any developer who has touched Nova — the entire surface is a config file and a menu registration, and a competent Laravel developer can reconstruct the package's behavior from first principles in well under an hour. This is the central product judgment: the package's value is convenience, not capability, and convenience of this magnitude rarely justifies a permanent dependency. Recommend a short source review, an explicit build-vs-buy decision, and a default lean toward in-housing unless the source demonstrates handling of Horizon authorization and URL resolution that would be tedious to reimplement correctly.
How can I help you explore Laravel packages today?