Rocketeers Laravel Laravel Package

Technical Evaluation

Verdict: v2.10.0 is a low-risk, additive minor release. It introduces one new signed read-only route plus Laravel 13 test coverage. No breaking changes, no deprecations, no schema changes. Recommend adopting for environments already instrumented by Rocketeers; treat the signed-URL/secret model as the item to review before enabling.

Architecture fit

• The package is a thin observability shim: one route (GET /rocketeers/horizon/stats) registered outside the web middleware group, returning aggregate Horizon counters only (status, processes, jobsPerMinute, failedJobs, recentJobs, wait).
• It does not touch application domain code, queues, models, or migrations. Horizon is a runtime-only dependency, and the route degrades to 404 when Horizon is absent.
• It deliberately coexists with the 2.9.0 bearer-token access path — two independent auth mechanisms, not a replacement. That is a clean separation but also means two things to reason about when troubleshooting access.
• The counterparty is the Rocketeers control plane, which signs URLs server-side and provisions ROCKETEERS_HORIZON_SECRET. The package is only useful inside that ecosystem; otherwise you are reimplementing the signer.

Integration feasibility

• Configuration is env-only (ROCKETEERS_HORIZON_SECRET, optional ROCKETEERS_HORIZON_ORIGIN, ROCKETEERS_HORIZON_TTL default 300s). No publish/migrate step described, which keeps onboarding to a composer bump plus one variable.
• New environments get the secret written automatically at provisioning; existing environments require a manual Insert › Horizon monitoring step in the env editor. That asymmetry is the most likely source of "it works in staging, not in prod" confusion.
• Manual verification is cheap: curl a signed URL, tamper/expire it and confirm 403, hit an app without Horizon and confirm 404.

Technical risk

• Secret quality. The HMAC key is the Rocketeers environment id. If that value is a UUID it is acceptable keying material for integrity, but it is also an identifier likely visible in dashboards, support screenshots, and logs. Need confirmation it is not exposed to end users; if it is, the signature provides integrity but not confidentiality of the signing capability.
• URL-borne credentials. A signed URL in a GET querystring lands in browser history, reverse-proxy access logs, APM traces, and potentially Referer headers. TTL (300s) bounds replay, and payload is aggregate-only, so severity is low — but throughput and failure-count data is still mildly business-sensitive.
• No stated rate limiting or nonce cache. Within the TTL window a captured URL can be replayed repeatedly. Acceptable given read-only aggregates; worth confirming whether the route is throttled by default.
• Fail-closed behaviour. An empty secret keeps the endpoint closed — the right default, but it fails silently, so a blank dashboard is the only symptom.
• CORS semantics. "No custom headers, so it stays a CORS simple request and never preflights" describes request classification, not response headers. The endpoint still needs to return Access-Control-Allow-Origin for the configured origin or the browser will block the response body. Flag as an integration check.
• Laravel 13 coverage. The runtime constraint (illuminate/support ^13.0) was already declared; only orchestra/testbench was capped, so this release makes 13 tested, not newly supported. Confirm the CI matrix still exercises Laravel 12, otherwise a green build stops being evidence for the majority of installed apps.

Key questions

1. Is ROCKETEERS_HORIZON_SECRET (the environment id) ever rendered in the dashboard UI, client-side JS, or shareable links?
2. Does the route set a CORS response header for ROCKETEERS_HORIZON_ORIGIN, and is the origin required or permissive by default?
3. Is there rate limiting or signature replay protection beyond the TTL?
4. What HTTP status is returned when the endpoint is "closed" by an empty secret — 403 or 404? On-call needs to distinguish this from the Horizon-not-installed case.
5. Does the stats collector read Horizon's Redis keys directly or via its repository contract, and how brittle is that across Horizon minor versions?
6. Does the testbench bump drop Laravel 12 from the CI matrix?
7. Is Horizon itself compatible with Laravel 13 at this point, independent of this package's test suite?

Integration Approach

Stack fit

• Laravel 10–12 at runtime (unchanged), with Laravel 13 now covered by the test suite against laravel/framework 13.29.
• Horizon optional per environment; Rocketeers recommended as the signing/dashboard counterparty.
• No overlap with existing auth, session, or CSRF machinery — the route bypasses the web group entirely, so there is no interaction with application middleware, policies, or tenant scoping.

Migration path

• Non-breaking minor bump: composer require / composer update to ^2.10.
• Existing 2.9.0 bearer-token consumers are unaffected — the release notes explicitly state the two mechanisms are independent.
• Newly provisioned environments need no action; existing environments need the one-time env-editor step before the dashboard's Horizon table populates.

Compatibility

• Verify Horizon version against the stats keys consumed.
• Verify CORS behaviour from the actual dashboard origin, not from curl (curl will succeed regardless).
• If you are still on Laravel 12, nothing changes functionally; the 13 coverage is a forward-readiness signal only.

Sequencing

1. Staging first: bump to ^2.10, set the secret, manually exercise valid / tampered / expired / no-Horizon cases and record the exact status codes for the runbook.
2. Confirm the CORS response from a real browser session against the dashboard origin.
3. Reconcile dashboard polling interval with ROCKETEERS_HORIZON_TTL (default 300s) — decide whether the dashboard re-signs per refresh or reuses URLs.
4. Roll to one production environment; watch for 403/404 volume before widening.
5. Only then treat Laravel 13 as a supported target in your own upgrade planning, and confirm Horizon's own 13 readiness.

Operational Impact

Maintenance

• Low steady-state cost: one route, three env vars, no migrations, no scheduled work. Maintenance is essentially "keep the secret in sync" plus changelog review; the release cadence appears small and incremental.
• Secret rotation is the one real ceremony: it must happen on the Rocketeers environment and the Laravel app together.

Support

• Expect recurring tickets that collapse to three causes: dashboard table empty or 403 (secret missing/mismatched between Rocketeers and app env, or an expired signature due to clock skew between the signing server and the app), 404 (Horizon genuinely not installed — expected, not an incident), or browser-side failure with a 200 in the access log (CORS misconfiguration).
• Document the 403/404 decision tree; it converts a class of "monitoring is broken" pages into a two-minute check.

Scaling

• Per-request cost is a handful of Horizon counter reads — cheap individually.
• Cost multiplies by instances × dashboard viewers × refresh interval, since polling is browser-driven. There is no stated server-side throttle, so a pinned tab left open or a shared screen can produce sustained background load across the fleet. Consider a client backoff or an edge rate limit if the instance count is large.
• Aggregate-only payloads keep response size flat and cacheable in principle, though signatures argue against shared caching.

Failure modes

• Empty secret → endpoint closed (fail-safe, silent; dashboards look dead rather than erroring).
• Invalid/expired signature → 403; dashboard shows stale or empty data.
• Horizon absent → 404; should be treated as informational.
• Horizon/Redis degraded → likely 5xx from stats collection (unverified; confirm and document).
• Half-completed secret rotation → 403 storm until both sides match.
• CORS regression → no server-side signal at all; only the browser console.
• Clock drift on the signing host → premature 403s that look intermittent and are hard to attribute.

Ramp-up

• Near zero for application developers — no code changes required.
• Roughly 15 minutes for on-call to learn the 403/404/blank-table triage path and the env-editor provisioning step.
• The only recurring human task is the existing-environment secret insertion; automating or documenting it in the environment bootstrap checklist removes the main source of setup drift.