Laravel Meridian Laravel Package

Technical Evaluation

Architecture fit

• Unchanged at the architectural level: Meridian remains a satellite package (service provider, own migrations, routes, gate, native queue event observers) and v1.6.0 ships no migration, which confirms the install/upgrade shape is stable across six minor releases. That is the strongest signal in this release for a TPM — it suggests the data model has settled and upgrade risk is low.
• The release's headline claim, "completes the parity with Laravel Horizon," is a positioning change worth noting to stakeholders. It sharpens the "Horizon for the DB driver" mental model, which is good for adoption, but the claim is functional parity, not operational parity — it does not imply Redis/SQS support, and it does not give you the years of production hardening Horizon has.
• The two-concern split from the original assessment still holds and must still be reviewed separately: read-side observability (now with a separate Silenced tab, metrics, JSON API) versus write-side supervision (php artisan meridian + pcntl/posix). This release improves both, but the balance of new risk lands on the write side — auto-scaling strategy and master memory limit are both supervisor behaviours that can change production outcomes.
• New scope: meridian:listen is a developer-experience feature with no production footprint, and the watch option adds a config surface (polled directories, --poll seconds). Keep it out of production review; it is a ramp-up and DX win only.

Integration feasibility

• Setup story is unchanged and still cheap: composer require + meridian:install, Blade dashboard, no front-end build. v1.6.0 adds meridian:listen which removes the last Node/npm dependency from local dev — this matters for CI images and for teams that refuse a JS toolchain, and it makes the package materially easier to evaluate, not just to run.
• Hard gates are unchanged and still the first thing to check: PHP 8.3+, Laravel 12/13 only, pcntl/posix for the supervisor. v1.6.0 introduces a memory_limit config key (default 64 MB) and a watch key; published configs and published Blade views now require attention at upgrade time, which is a small but real new upgrade step.
• Upgrade path is clean — composer update, no migration — but the behavioural changes are the integration risk, not the schema:
  • Long-wait defaults changed: a queue absent from waits now falls back to '*', and to 60 seconds when '*' is not set. Previously it was ignored. Any team that never configured waits will go from "no long-wait alerts" to "alerting at 60s across every queue" the moment they upgrade. This is the single most likely way this release causes an incident.
  • Silenced jobs are now retained (status silenced) until meridian:prune removes them, and they now count in metrics. Prune configuration is no longer a nice-to-have on upgrade; it is a prerequisite.
• viewMeridian gate and route configuration are unchanged, so the authorization seam is intact. Payload/exception retention questions remain unanswered by this release.

Technical risk

• Package maturity (reduced, still material): six minor releases since v1.0.0 with a coherent feature narrative (log scaling, memory limit, silenced tab, dev listener) is evidence of an active, competent maintainer. That is a real improvement over the "first release, unknown cadence" position. What is still absent: published support policy, security disclosure process, deprecation/back-compat guarantees, and any statement about funding or bus factor. Rapid version progression also cuts both ways — it implies churn and a config surface that is still moving.
• Coupling to Laravel internals (unchanged, medium): history still depends on queue events plus an import-from-jobs-table fallback. Nothing in this release reduces that coupling. Upgrade-testing against each Laravel minor is still required.
• Write amplification (worsened, medium): retaining silenced jobs until prune increases history-table volume on top of normal completed-job rows, on the same database that brokers the queue. The retention question moves from "tune it later" to "size it before the pilot."
• Supervisor lifecycle gap (partially closed, medium): the master memory limit (default 64 MB, 0 to disable) means the master exits with code 12 after draining running jobs, firing MasterSupervisorOutOfMemory. That is the correct design — graceful drain, not a kill — and it closes a real leak. But it transfers responsibility: it assumes a process monitor exists and actually restarts on exit 12. Without one, the new behaviour converts a slow memory leak into a clean but permanent shutdown. It also introduces a tuning hazard: 64 MB is low for a process supervising many workers, and a mis-set limit produces a restart loop rather than an outage you can see.
• Auto-scaling semantics (new, medium): the log strategy allocates worker processes by the logarithm of each queue's pending depth, so one huge queue cannot monopolise the pool. That is a better default for multi-queue deployments, but it is a second behaviour (alongside auto/simple/none) that changes how many workers a given queue actually gets. Teams should not change scaling strategy and supervisor ownership in the same change window.
• Privileged actions and data exposure (unchanged, medium): retry/cancel from the UI still mutates production job state; payloads and exception traces are still persisted and queryable. The new Silenced tab adds another surface where job metadata is browsable, and the gate remains the only control.

Key questions

1. Support policy, license terms, security disclosure process, and maintainer backing — still unanswered, and now the dominant remaining risk given the package's feature velocity.
2. Guidance for the new memory_limit default: what master size should be expected per N workers, and what restart backoff does the maintainer recommend so exit-12 does not become a flapping loop?
3. Storage cost per job, and are payloads truncatable/redactable? This is now more urgent because silenced jobs are retained and counted in metrics.
4. Behavioural migration for long waits: is an opt-out (retain legacy "ignore unlisted queues") planned, or is the 60s default permanent?
5. Is the package database-driver-only, or does "Horizon parity" imply partial redis/sqs support that changes the Horizon comparison?
6. Default autoScalingStrategy, and how log interacts with queue priority and auto — what happens on worker crash under each?
7. Is php artisan meridian intended as a singleton (multi-node, Octane)? Unchanged and still important.
8. Do retry/cancel emit audit records, and does the Silenced tab respect the same gate as Completed?
9. meridian:prune defaults and per-status retention — specifically, is silenced retention separately configurable from completed?
10. Is there now a stated policy for meridian_* migrations and config keys (the "defaults apply when missing" pattern is good — is it a guarantee)?

Integration Approach

Stack fit

• Fit profile is unchanged: single-database Laravel monoliths and modular monoliths on L12/L13, PHP 8.3+, running queue:work under systemd/supervisord, no Redis and no appetite to add it.
• v1.6.0 broadens fit in two directions: multi-queue deployments get a genuinely better default story via the log strategy, and dev teams gain a no-Node local listener. It narrows fit nowhere.
• Still a weak fit for: high-throughput pipelines, multi-tenant setups where job payloads mix tenants, Windows-only dev teams (dashboard only, no supervisor), and polyglot topologies. State the boundary explicitly: observability and supervision for the DB driver — not a Horizon replacement for Redis shops and not a migration path off Redis.

Migration path

• Upgrading from an earlier Meridian install: composer update, then two config additions (memory_limit, watch — defaults apply if missing), then republish Blade views if they were published. No migration, no data backfill.
• From nothing: two commands, unchanged. Still observe existing queue:work processes via heartbeats, so observability can land before supervision.
• The migration that needs a plan is alerting behaviour, not data: audit waits before upgrading. Either populate waits explicitly per queue, or consciously accept the 60s default, or set 0 on queues that should not alert.
• Reversibility remains good and is now slightly better: master memory limit and scaling strategy are config-only knobs, so behaviour can be dialled back without a code change.

Compatibility

• PHP 8.3 across app, CI and all runtime images; pcntl/posix present in the built production image.
• Single scheduler host (or guarded snapshot/prune) for multi-node deploys; unchanged.
• Process monitor must be configured to restart the master on exit code 12, and to alert if it restarts more than N times in M minutes.
• Route middleware composition verified against SSO/2FA/IP allowlisting before dashboard exposure; unchanged, and the new Silenced tab must be confirmed to sit behind the same gate.
• Local dev requires --poll tuning on network filesystems / Docker-on-macOS bind mounts where file-change polling is unreliable.

Sequencing

1. Before upgrading — alert audit. Dump the current waits config and decide per queue: explicit wait, 0 to disable, or accept 60s. Populate config first, then upgrade, so the new default never takes effect unconfigured.
2. Week 1 — read-only trial in staging. Install/upgrade, add memory_limit and watch keys, run migrations if new, enable history on one low-volume queue. Measure row growth including silenced jobs. No supervisor change.
3. Week 1–2 — secure the surface. viewMeridian mapped to real roles, middleware/domain/prefix set, JSON API confirmed non-anonymous, payload retention decided, Silenced tab included in the authorization test. Add a 403 assertion for both web and API routes.
4. Week 2 — retention and alerting. Set meridian:prune cadence against measured growth, confirming silenced retention is covered. Tune LongWaitDetected to a single owner per connection:queue.
5. Week 3 — supervisor pilot on one non-critical queue. Run under systemd with restart policy, a liveness check, and an explicit note that exit code 12 is expected-and-restart. Start with the existing scaling strategy; change to log only after baseline load is understood. Keep queues disjoint from legacy workers.
6. Week 3–4 — production read-side + dev enablement. Ship the dashboard and runbook to on-call; roll meridian:listen out to the team as the standard local workflow, with --poll guidance for Docker/WSL.
7. Week 4+ — supervisor cutover and scaling-strategy change, one queue at a time, with documented fallback to queue:work.

Operational Impact

Maintenance

• Recurring duties now include a new one: watch master restarts. Exit code 12 is healthy behaviour, but it must be distinguishable from a crash, and repeated 12s mean the memory_limit is mis-set.
• Config surface grew (memory_limit, watch, waits semantics, autoScalingStrategy). Config drift across environments becomes a plausible failure source; keep config/meridian.php in version control and diff it at upgrade.
• Published Blade views are now a republish-on-upgrade obligation. Prefer not publishing them unless customised — an easy review comment.
• Upgrade risk still concentrates on Laravel minors (queue events, jobs table shape). Pin the package, upgrade alongside Laravel, and keep a staging queue that exercises batch/bulk/pushRaw paths.
• Maturity risk is lower than at v1.0.0 but governance is still unaddressed: assume you may need to fork or vendor, and keep the package behind a thin application-level adapter rather than referenced in dozens of places.

Support

• Support posture remains the weakest dimension: single-vendor namespace, no published SLA, no visible security process. Velocity is reassuring; governance is not. Realistic model is still "we support it ourselves, upstream may help."
• The meridian:listen feature reduces a specific support burden — dev-environment setup issues — which is a genuine, if modest, operational saving.
• On-call runbook must be updated for this release: meridian:status, pause/continue/terminate, retry/cancel, what "long wait" means (now 60s by default), what exit code 12 means and what to do, and how to tell a scaling-strategy problem from a throughput problem.

Scaling

• Three DB-bound axes unchanged: history table size, jobs-table polling cost, worker count against one database. Silenced-job retention adds to the first, and it is the one that will surprise teams who sized prune before upgrading.
• The log auto-scaling strategy is a real improvement for multi-queue deployments — it prevents head-of-line queues from starving small ones — but it does not add throughput. The database remains the ceiling. Keep the pre-agreed exit threshold (sustained volume or wait time at which the team moves to Redis/SQS + Horizon).
• Multi-node still needs an explicit decision on supervisor placement and duplicate snapshot/prune execution.

Failure modes

• Long-wait alert storm on upgrade (new, high likelihood): teams with no waits config go from silent to 60s alerting on every queue simultaneously. Mitigation: populate waits before upgrading; single recipient per queue; flap suppression.
• Master restart loop (new, medium): memory_limit set too low for the worker count → exit 12 → restart → exit 12. Mitigation: size the limit against worker count, add a restart-rate alarm (not just a liveness check), and know that 0 disables the guard entirely.
• Silenced-table bloat (new, medium): retained silenced rows plus existing history on the queue's own database. Mitigation: growth alarm, confirm prune covers silenced, re-baseline retention at pilot.
• Silent worker starvation (unchanged, high impact): supervisor dies, no workers, queue depth grows invisibly. Mitigation: external watchdog and alerting on queue age, not just failures — and now also on master restart rate.
• pcntl/posix absent: supervisor cannot start in the target image; may only surface in production if dev images differ. Mitigation: verify in the built image, add a startup assertion.
• Scaling-strategy mis-tune (new, low/medium): log under-allocates workers to a genuinely large single queue in some shapes; changing strategy and supervisor ownership in the same window makes the regression hard to attribute. Mitigation: sequence the changes.
• Authorization regression: route or gate misconfiguration exposing payloads/exception traces, now including the Silenced tab. Mitigation: automated 403 tests across web and API.
• Duplicate consumption during rollout: Meridian supervisor and legacy workers on the same queue. Mitigation: queue-disjoint rollout, documented.
• Privileged action misuse: retry/cancel storms masking an underlying failure. Mitigation: audit log review, restrict to on-call role.

Ramp-up

• Unchanged and still low for Laravel developers: Blade UI, familiar artisan verbs, Horizon-familiar vocabulary. meridian:listen makes local setup meaningfully faster — no Node, no npm, one command. Install/config/staging verification remains ~0.5 day.
• ~0.5 day new: pre-upgrade waits audit and long-wait re-baselining, plus memory_limit sizing against expected worker count.
• ~1 day for route hardening, gate-to-role mapping, API exposure and Silenced-tab authorization tests.
• ~1 day for supervisor deployment under systemd with watchdog, restart-rate alerting, exit-12 handling, and runbook.
• ~0.5 day for retention/pruning (now including silenced rows) and long-wait alert tuning once real growth data exists.
• Total: roughly 3.5 engineer-days to a defensible production rollout — up modestly from v1.0.0 because the release adds two production behaviours (memory limit, log scaling) and one alerting default change, offset by reduced maturity and dev-setup risk.
• Recommend gating GA on: the security review of dashboard/API (including Silenced), a written fallback to plain queue:work, and a confirmed waits configuration that was in place before the upgrade.