- What is Vigilance and how is it different from Laravel Horizon?
- Vigilance is a driver-agnostic control center for Laravel queues, jobs, Artisan commands and the scheduler, shipped as a self-contained Livewire dashboard at /vigilance. Unlike Horizon, which only supervises Redis queues, Vigilance records runs for every queue driver including database, Redis, SQS, Beanstalkd and sync. It also captures the full queued to running to done or failed lifecycle, monitors scheduled tasks for late, failed and grace outcomes, and adds a manual control plane for dispatching jobs and running allowlisted commands.
- Which queue drivers does Vigilance support?
- Vigilance works with every Laravel queue driver: database, Redis, SQS, Beanstalkd and sync. Because capture rides on framework events like JobProcessed, JobFailed and CommandFinished rather than a specific backend, no driver-specific agent or sidecar is needed. The worker supervisor has been validated across database, Redis, SQS and Beanstalkd with a multi-process chaos battery covering autoscaling, crash recovery and graceful shutdown.
- How do I install Vigilance in a Laravel application?
- Install it with composer require anousss007/vigilance, then run the vigilance:install command, migrate, and define a viewVigilance gate to authorize dashboard access. No Filament or Livewire knowledge is required because the package ships its own standalone UI, and there is no external service or infrastructure to provision. The vigilance:doctor command diagnoses misconfiguration during first-week setup.
- Does Vigilance support Laravel 10 or Laravel 11?
- No. Vigilance requires PHP 8.2+, Laravel 12 or 13, and Livewire 3.5+ or 4 as a transitive dependency. For a modern Laravel application that is frictionless, but on Laravel 10 or 11 it is a hard blocker rather than a configuration issue. Frontends with a strict Content Security Policy should also review Livewire asset inclusion before adopting it.
- Why does the Vigilance dashboard return a 404 or redirect to a login page?
- The dashboard route inherits the web middleware group by default, so apps with locale prefixing, global auth redirects, teaser or maintenance middleware can misroute or 404 the dashboard. This is a documented integration gotcha rather than a config toggle, and it usually requires adjusting the route prefix or middleware in config. Budget a short integration task for any app with non-trivial global middleware.
- Is it safe to dispatch jobs and run Artisan commands from the Vigilance dashboard?
- The manual control plane is effectively remote-code-execution adjacent, so treat dashboard compromise as code execution and scope the threat model yourself. Vigilance mitigates this with deny-by-default authorization through the viewVigilance gate, local-only access until you bind it, double gating via VIGILANCE_CONTROL_ENABLED and VIGILANCE_MCP_ALLOW_WRITES, command allowlists and audit logging. Keep control features disabled in environments that do not need them.
- Will Vigilance bloat my production database with captured runs?
- Vigilance writes one lifecycle-updated row per run, so storage does grow with traffic, but the package ships the production controls to contain it. That includes sampling at dispatch, payload size caps, secret redaction, a capture guard, opt-in per-page cost metrics, retention and prune commands, and support for a separate database connection. Plan your retention window and connection before enabling it on a high-throughput queue.
- Can Vigilance replace Horizon, Telescope, Pulse and Sentry in one package?
- That consolidation is the main architectural argument: one dashboard for jobs, commands, scheduler, grouped fingerprinted errors, whole-app APM with p50/p95/p99 and Apdex, per-route metrics, RUM and a worker supervisor. It also removes the forced Redis dependency that Horizon imposes on worker supervision. The trade-off is scope, since those layers share one storage schema and one dashboard, so evaluate Vigilance as a platform component rather than a small utility.
- Does Vigilance run its own migrations and can I control them?
- Yes, Vigilance auto-loads its migrations, which places its schema into your application's migration graph. Teams with reviewed, gated or hand-applied migration governance lose that control by default, so publish or disable the migrations if that matters to you. This is a real integration consideration for regulated or heavily reviewed deployments.
- Is Vigilance production-ready and actively maintained?
- The package takes a production-first posture with sampling, size caps, secret redaction, retention and secure-by-default authorization, and its capture, storage, metrics, tracing and supervisor layers are covered by tests including a real multi-process chaos battery. The main risk is adoption: it is a single-maintainer package with roughly 207 GitHub stars and no dependents, so you would be an early adopter with no crowd-sourced failure modes to lean on. Pin versions, review upgrades, and keep a fallback observability path while it matures.