Laravel Laravel Package

Technical Evaluation

What shipped (v2.10.0)

1. A new signed, read-only HTTP endpoint: GET /rocketeers/horizon/stats?expires=<ts>&signature=<hmac>. It returns aggregate Horizon counters only (status, processes, jobsPerMinute, failedJobs, recentJobs, wait). It cannot reach job payloads or Horizon's action endpoints, and it is explicitly narrower than the bearer-token access introduced in 2.9.0. The two coexist and are independent.
2. Real Laravel 13 coverage. illuminate/support already allowed ^13.0, but orchestra/testbench was capped at ^10.0, so CI only ever booted Laravel 12. Testbench 11.x now resolves laravel/framework 13.29, so Laravel 13 is genuinely exercised.

Architecture fit

• The endpoint is registered outside the web middleware group: no session, no cookies, no CSRF, no custom headers. That makes it a CORS "simple request" that never preflights, and stateless by construction. This is the right shape for a machine-signed, browser-polled read path.
• Security posture is fail-closed in the two cases that matter: an empty secret keeps the endpoint closed, and Horizon being absent yields 404 so the package remains safe in apps that don't run Horizon.
• The trust model is HMAC-over-expiry with a short TTL (default 300s), signed server-side by the dashboard so only the signature — never the secret — reaches the browser. That is a standard, defensible pattern for embedding a live infra widget without handing the browser credentials.
• The main architectural reservation is what the secret is. The docs say to set ROCKETEERS_HORIZON_SECRET to "your Rocketeers environment id", i.e. a provisioning identifier is being used as an HMAC key. That is only acceptable if the value is high-entropy and rotatable; environment IDs are often displayed in dashboards and URLs.
• Second reservation: this is a vendor-platform read path into production. Even scoped to aggregate counters, it means a third-party SaaS dashboard can poll live operational metadata from every Horizon instance. That deserves explicit security/governance sign-off, not just a composer bump.

Integration feasibility

• Purely additive. No breaking changes, no deprecations, no config keys removed, no schema or migration work. Existing installs that do nothing keep working: with no secret set, the route stays closed.
• Rocketeers-provisioned environments get the secret written automatically; existing environments need one manual step (Insert › Horizon monitoring in the env editor). ROCKETEERS_HORIZON_ORIGIN and ROCKETEERS_HORIZON_TTL are optional.
• Enabling it is config-only; disabling it is unsetting one env var, with immediate effect on the next request.

Technical risk

Key questions for the vendor

1. Which HMAC algorithm, and is comparison constant-time (hash_equals)?
2. Is expires validated for both past and far-future values, and is there any nonce/replay protection?
3. Is rate limiting applied to the route outside the web group?
4. Is the Rocketeers environment ID high-entropy, and is there a rotation procedure that doesn't require re-provisioning?
5. What Access-Control-Allow-Origin behaviour should we expect, given no custom headers are sent?
6. Does the secret scope to a single environment, or can one value read stats across environments?
7. Can the 2.9.0 bearer-token path be disabled independently while keeping the signed endpoint?

Integration Approach

Stack fit

• Laravel applications running Horizon — the only population for which this does anything. Apps without Horizon get 404 and no behavioural change.
• Best fit for teams already on Rocketeers hosting; for everyone else this is dormant code that still expands the route table and needs a security review before the secret is ever set.
• Requires the Rocketeers dashboard as the counterparty. There is no self-hosted consumer of this endpoint, so the value is entirely contingent on adopting that platform's monitoring view.

Migration path

1. Upgrade the package to ^2.10.0 in a non-production environment first; confirm route registration and that /rocketeers/horizon/stats returns 403/404 as expected before any secret exists.
2. Set ROCKETEERS_HORIZON_SECRET per environment via the Rocketeers env editor (existing environments) or accept the auto-provisioned value (new ones).
3. Optionally pin ROCKETEERS_HORIZON_TTL and ROCKETEERS_HORIZON_ORIGIN if defaults don't fit your polling cadence or ingress layout.
4. Decide the fate of the 2.9.0 bearer-token access: keep both, or retire the bearer path if the signed endpoint covers the need.
5. Promote through staging to production, watching for 403 (signature/secret/skew) versus 404 (Horizon absent) versus 5xx (Horizon/Redis unhealthy) as distinct signals.

Compatibility

• No PHP or Laravel minimums raised; illuminate/support ^13.0 was already declared. The only dependency movement is the dev-time testbench bump to 11.x, which does not affect runtime.
• Laravel 13 support moves from "declared" to "tested" — relevant if you're planning a framework upgrade and were treating this package as a blocker.
• No config file publication or cache-clearing step implied; env-var driven.

Sequencing

• Lowest-risk order: package bump → verify closed-by-default behaviour → security review of the new route → enable secret in staging → enable in production → retire redundant bearer access.
• If a Laravel 13 upgrade is on the roadmap, take this release before the framework jump so the test matrix is honest when you cut over.
• If Rocketeers adoption is not decided, upgrading is still safe but the endpoint should stay unconfigured; the 404/403 defaults make "installed but off" a legitimate steady state.

Operational Impact

Maintenance

• Low and vendor-owned. Additive release, no migrations, no scheduled tasks, no cache or queue surface. The upgrade itself is a composer bump plus one env var per environment.
• The one standing maintenance obligation is secret lifecycle: knowing where ROCKETEERS_HORIZON_SECRET is set, who can read it, and how it gets rotated if the environment is rebuilt or the value is suspected exposed.
• Ongoing cost is mostly cognitive: a second, independent access mechanism (bearer from 2.9.0 plus signed from 2.10.0) must be understood by anyone auditing the app's public routes.

Support

• Failure is diagnosable from status codes alone: 403 = signature invalid/expired/secret mismatch/skew; 404 = Horizon not installed; 5xx = Horizon or Redis unhealthy. That is unusually clean triage for a package route and should be documented in the runbook.
• Support burden concentrates on the first enablement per environment — specifically the "existing environment needs the secret inserted manually" step, which is easy to miss and presents as a silently empty dashboard rather than an error.
• Because the secret is tied to a provisioning identifier, environments cloned or restored from another environment can inherit the wrong value; that should be an explicit checklist item.

Scaling

• Negligible. The endpoint reads aggregate counters, not job payloads, and does no per-job fan-out. Cost is one Horizon/Redis aggregation per poll, times the number of dashboard viewers.
• Polling is browser-driven, so aggregate request volume scales with observers, not with queue throughput — but a dashboard left open in many tabs multiplies polls. Confirm the TTL and any throttling are set with that in mind.
• Stateless and session-free, so it scales horizontally like any other route and adds no sticky-session or shared-cache requirement.

Failure modes

• Secret unset → endpoint closed; dashboard shows nothing. Fail-safe, but silent.
• Secret mismatch or stale value → 403; dashboard stays empty with no obvious cause in the app logs unless the 403s are surfaced.
• Clock skew beyond TTL → intermittent 403s that correlate with one host, which is a classic misleading symptom.
• Horizon/Redis degraded → 5xx; monitoring widget fails at exactly the moment it's most wanted. Treat dashboard availability as non-critical and don't alert on it.
• Secret exposure → read-only aggregate counters only; no job payloads and no Horizon action endpoints reachable. Blast radius is bounded and informational, which is the strongest argument for this design over the bearer token.
• Horizon not installed → 404, no noise. Acceptable.

Ramp-up

• Developer ramp-up is near zero: no code to write, no API to learn. The whole integration is one env var plus optional TTL/origin.
• Ops ramp-up is modest but real: the team needs to own the secret (placement, rotation, per-environment correctness), understand the four status codes, and know that disabling the feature is an env-var change rather than a deploy.
• Security review is the genuine upfront cost — a new externally reachable route on production apps, plus a decision on whether the 2.9.0 bearer path stays. Budget that review even though the code change is trivial.

Assessment: upgrade. Additive, low-risk, fail-closed by default, and it closes a real gap by actually testing Laravel 13. The gating items are procedural, not technical: confirm the HMAC secret is genuinely high-entropy and rotatable, confirm throttling applies outside the web group, and make a deliberate decision about keeping or retiring the broader 2.9.0 bearer access before turning the endpoint on in production.