- How do I install kaiserkiwi/nova-queue-management?
- Install it with Composer by running composer require kaiserkiwi/nova-queue-management in your Laravel application. Then add the tool to the tools() array in your NovaServiceProvider. No migrations and no config publishing are required for the zero-config path. Installation itself is roughly a half-day of work; the real effort is wiring up authorization around the destructive actions.
- Does this package require a Laravel Nova license?
- Yes. It is a Nova tool rather than a standalone dashboard, so your application must already be licensed for Laravel Nova; without that license the package is not adoptable. Keep in mind that Nova is commercial and closed source, so every Nova major is a paid upgrade, and this package's support horizon is tied to that cadence plus one maintainer's interest.
- Which queue drivers does this Nova queue tool support?
- It reads and writes Laravel's own queue tables, jobs, job_batches and failed_jobs, so it inherits whatever driver topology you already have configured, including database, Redis and SQS. It is not a driver or a scheduler and does not replace your queue backend. Database and SQS teams get the most value, since they otherwise triage failures over SSH with artisan queue:failed.
- How do I register the tool in NovaServiceProvider?
- Add the tool to the tools() array returned by app/Providers/NovaServiceProvider.php. That single registration is the entire integration, and it touches nothing in your application domain. There is no service provider surgery, no schema change and no event hook to maintain.
- Does it support Laravel Nova 5 and Laravel 12?
- Release 1.4.0 widened the laravel/nova constraint to admit Nova 5 through an outside contributor's pull request, but there is no CI evidence that the Nova 5 path was actually exercised. Read composer.json directly to see whether the constraint is a dual-run ^4.0|^5.0 bridge or whether Nova 4 support was dropped, because that determines your upgrade sequencing. Also verify the php and laravel/framework floors and ceilings to confirm whether Laravel 12 is reachable.
- How do I control who can retry or delete queue jobs in Nova?
- The package does not ship authorization gates or policies for its destructive actions, so you have to add them yourself. Retry, delete and flush act directly on production queue tables, which means a missing or misconfigured gate causes data loss rather than a degraded page. Wrap those actions in Nova policies or custom gates and make sure destructive actions are attributed to a user.
- How is this different from Laravel Horizon?
- Horizon is Laravel's first-party queue dashboard for Redis-backed queues, so for Redis teams this tool overlaps with a UI you already have. For database and SQS teams it is genuinely complementary, since Horizon does not cover those drivers. Decide based on your driver topology rather than expecting feature parity.
- Can I test this tool safely before using it in production?
- Yes. Install it in a staging environment with a Nova license and a copy of your queue tables, then exercise retry, delete and flush against representative data volumes. Because there are no migrations and no required config publishing, adding and removing the tool registration carries little risk. Reverting is as simple as removing the Composer line and the tools() entry, which makes the integration cheap to reverse.
- Is bulk retry or flush safe on a large failed_jobs table?
- Bulk retry and flush are synchronous web requests against failed_jobs, so timeouts and lock contention are plausible precisely when the table is largest, during an incident. Behavior at volume is unproven by the maintainer, and pagination and indexing beyond roughly ten thousand rows should be tested. For very large tables, consider chunked retries or artisan commands instead of a single bulk action.
- Is kaiserkiwi/nova-queue-management maintained, and what license does it use?
- It is a maintained fork of the abandoned den1n package, but it is a single-maintainer project with few stars and no dependents, best-effort GitHub issues and no SLA. The declared license is NOASSERTION, meaning GitHub could not classify it, so legal should resolve it to a known OSI license before production use on a privileged surface. Escalation latency is unbounded, so plan for that risk before committing.