- How do I install and set up johnrivera7/filament-antivirus?
- Install it with Composer using johnrivera7/filament-antivirus, then publish and review the package configuration and run the migration that creates the antivirus_incidents table. ClamAV must be installed and reachable on the host, either as a running clamd daemon or as the standalone clamscan binary. After that, attach the AntivirusFileRule validation rule to the FileUpload fields you want protected in your Filament forms and resources.
- Which Laravel and Filament versions does this package support?
- The package is assessed as feasible on Laravel 10, 11 and 12 with Filament 3.x on a Linux host that has ClamAV available. However, no formal Laravel or Filament version matrix has been published, so support beyond that combination is unverified. Pin your Laravel and Filament versions, lock Filament minors in CI, and test upgrades before rolling them out.
- How does the antivirus scan hook into Filament file uploads?
- Scanning is done through the AntivirusFileRule validation rule, which you attach to individual FileUpload form fields. Filament validates the Livewire temporary upload before the file is persisted, so a correctly attached rule scans the file pre-write rather than after it lands in storage. The rule is opt-in per field, so nothing is scanned unless you add it yourself.
- Does the package protect every upload path in my Laravel application?
- No. Only Filament form fields with the AntivirusFileRule attached are scanned, which means custom API endpoints, CSV and import pipelines, queued jobs, console commands and any non-Filament controller are uncovered. Coverage depends on developer discipline and degrades silently as new upload surfaces are added. Keep an inventory of upload paths and treat the rule as mandatory on every new FileUpload field during code review.
- Should I use clamdscan or clamscan in production?
- Use clamdscan in production. clamdscan is a thin client against a running clamd daemon and returns results quickly, while clamscan is a standalone binary that reloads the full signature database on every invocation, costing seconds of latency and roughly a gigabyte of RAM per scan. That difference is the difference between a usable upload gate and a Livewire timeout, so pin the driver explicitly in configuration and assert it in your deployment checks.
- What happens if ClamAV is unreachable or the scan fails?
- The package documentation does not define this behavior, so the fail-open versus fail-closed decision is yours to make. Treat it as an explicit product decision and document the default rather than letting it happen by omission. Whatever you choose, test the unreachable-ClamAV path in staging so rejected uploads and error states behave predictably for users.
- How does the quarantine manager and security dashboard work?
- The package ships a Filament Antivirus Dashboard and a quarantine manager backed by the antivirus_incidents table, so flagged uploads are recorded as incidents rather than silently vanishing. Before relying on it, confirm that the incident records capture the uploader, tenant, filename and timestamp you need for auditing. Also write a restore runbook, since a quarantine workflow only helps if there is a defined path for releasing legitimate files caught by a false positive.
- Can I disable antivirus scanning in local development?
- A null driver is available for local environments, which effectively turns the control off. Because that same config value could drift into production, guard it in CI by failing the build if the null driver is active outside the local environment. Keep staging and production pinned to a real ClamAV driver so you catch integration problems before release.
- Does it scan files that are already stored in my application?
- No. Scanning happens at upload time through form validation, so there is no retroactive sweep of your existing file corpus. If you need assurance about previously uploaded files, plan a separate batch scan against your storage buckets. Treat the package as a gate for new uploads, not as a historical audit tool.
- Is this package safe to depend on in production, and what are the alternatives?
- The package is a first-ever v1.0.0 release from a single maintainer with very low download and dependent counts, so its semver promise is effectively unearned and you should treat it as 0.x. Many teams vendor or fork it into their own monorepo, which is reasonable because the differentiated value is the dashboard, incident table and quarantine UI, while the scanner itself is just a call to ClamAV. If you would rather not depend on it, a custom validation rule or a Flysystem-level scanner wrapper gives you the same protection with full control over fail behavior and coverage.