- What does den1n/nova-queues do?
- It is a Laravel Nova resource package that adds a queue management panel inside the Nova admin dashboard. You can browse pending, running, completed, and failed jobs, retry or delete failures, and watch queue activity without leaving Nova. It is a presentation and operations layer only, so it does not change how your application dispatches or processes jobs. It is relevant only if your project already runs Laravel Nova.
- How do I install den1n/nova-queues?
- Installation is a standard Composer require of den1n/nova-queues followed by Nova resource registration. The service provider is auto-discovered, so there is typically no manual provider entry needed in Laravel. Because the package reads your existing queue tables, you should not expect migrations of its own. Run the install in a non-production environment first and confirm the registered resource renders against real queue data.
- Which Laravel and Nova versions does den1n/nova-queues support?
- The package targets the Laravel Nova resource API, but you must check its composer.json constraints before relying on it. The repository is archived, so it will not receive updates for new Laravel or Nova majors, and Nova 4 and 5 changed resource and authorization behavior. Validate the declared constraints against your current app matrix rather than assuming compatibility. If your project is on a recent Laravel or Nova release, expect to patch the package yourself.
- Does den1n/nova-queues work with Redis or Horizon queues, or only the database driver?
- The package is designed around the standard jobs and failed_jobs tables, which means it is a natural fit for database-backed queues. Behavior with Redis or Horizon depends on whether those tables are still populated in your setup, and that is not guaranteed. If you use Horizon, its built-in dashboard already covers this ground with official support. Test against your actual driver before assuming parity with the database driver.
- Is den1n/nova-queues still maintained?
- No, the repository is archived, so there are no upstream fixes, security patches, or compatibility updates. Adoption is also low, meaning few people have exercised edge cases and there is unlikely to be a meaningful test suite or CI pipeline. If you adopt it, fork it into an internal namespace, pin the commit, and assign an owner. Treat it as an internal tool with a maintenance budget rather than a supported dependency.
- Can I retry or delete failed jobs from the Nova dashboard?
- Yes, retry and delete controls for failed jobs are part of the described feature set. These are destructive actions, so be careful: retrying a job that partially executed can duplicate side effects, and deleting a failure loses the payload needed for diagnosis. Make sure only trusted operators have access to the resource. Consider adding your own guards or confirmation steps if your fork allows it.
- How do I secure queue payloads shown in Nova?
- Queue payloads frequently contain personally identifiable information or application secrets, so a UI that surfaces them needs proper authorization. Check whether the package ships Nova policies for viewing payloads and for retrying or deleting jobs, and add your own if it does not. Restrict the resource to operators who genuinely need it, and consider audit logging for destructive actions. In multi-tenant environments, payload isolation should be a hard requirement before enabling the panel.
- Is den1n/nova-queues safe to use in production?
- Risk here is high and driven by project health rather than code complexity, so direct production use of the upstream package is not advisable. The safest path is to fork it, pin the commit, record the exact Laravel and Nova versions you validated, and review its dependency tree for advisories. Start with a short spike in a non-production environment using real queue data. If the spike does not show clear value, remove it before it becomes load-bearing.
- What are the alternatives to den1n/nova-queues?
- Laravel Horizon's built-in dashboard covers Redis queues with official support, and Laravel Pulse plus Telescope give broader visibility into queue and job behavior. External observability tools like Sentry or Datadog handle failure alerting and history well. A small custom Nova tool that queries the same tables with your own authorization is a few days of work and avoids the archived-dependency problem entirely. For most teams already on Horizon or Pulse, this package duplicates functionality with less support.
- How should I evaluate den1n/nova-queues before adopting it?
- Sequence the work: review composer.json constraints, the dependency tree, and any known advisories first. Then run a non-production spike where you install the package, register the resource, and verify the read views against real queue data using your actual driver. Finish with a security review of payload visibility and retry or delete authorization. Only after those steps should you decide whether to maintain an internal fork or drop the package.